保存成功
保存失败,请重试
提交成功

面试需要知道的 TCP 知识

作者/分享人:Allen()
BAT高级研发工程师,CSDN 博客专家。目前从事服务器相关的开发。负责过大流量、高并发等业务场景。 个人博客:https://allen.blog.csdn.net

TCP 是一套相当复杂的协议,包含的内容也非常多,面试也非常常见,不少新手遇到 TCP 相关的面试就吓到了,学的也是一头雾水,不知道如何下手,也不知道从何看起,拿起 TCP/IP 详解,也找不着重点,看两页就犯困。

为了解决大家的困惑,花了两天的时间,帮大家梳理一下,作为一名开发者,应该需要重点掌握哪些 TCP 知识。

在本场 Chat 中,会讲到如下内容:

  • 如何理解 TCP 首部字段
  • 三次握手与四次挥手实验
  • 学习 tcpdump 基本用法
  • Delay ACK 实验
  • Nagle 算法实验
  • 流量控制与拥塞控制
  • MSS/MTU/TIME_WAIT
已有1236人预订
预订达标
文章出炉
     
19.09.03
19.09.09
本场 Chat 文章已出炉,购买后即可阅读文章并获得一张Allen()的读者圈Pass
请务必添加GitChat服务号以查看活动进度及获取活动通知。
查看文章评论/提问
anyang2 个月前
向大佬低头。。。。。。
rzet3 个月前
请教作者一个小白问题。 A向B发送数据包a,如果因为网络延迟问题导致重传,就是A向B发送了两次a,最后B两个包都收到了,怎么处理这个两个重复包?是丢弃后面收到的包?(因网络延迟等问题,可能会导致多个包被多次发送,而对方最后都收到了,如何处理)
Z.K.4 个月前
都是干货! 纠正了我很多错误的认知,尤其是实验部分,太赞了!
hlxing4 个月前
Allen巨巨,今天看了第三遍,发现 Nagle 算法背景中的糊涂窗口综合症的举例存在问题。 这个举例是接收端引起的糊涂窗口综合症,可以通过前面所说的延迟确认解决,而 Nagle 算法解决的应该是发送端引起的糊涂窗口综合症。如果采用 Nagle 直接发送合并的大分组,无法保证接收端可以正常接受,可能会小于滑动窗口。 对于发送端引起的糊涂窗口综合症,是由于发送端产生数据慢,例如一次产生一个字节的报文,导致 TCP 利用率不高,采用 Nagle 可以在等待上一个分组的 ACK 的同时,合并大分组,进而发送出一个大的报文,减少报文数量。 参考: 百度百科-糊涂窗口综合征(https://baike.baidu.com/item/%E7%B3%8A%E6%B6%82%E7%AA%97%E5%8F%A3%E7%BB%BC%E5%90%88%E5%BE%81/6167377?fr=aladdin)
hlxing回复Allen()(作者)4 个月前
在维基百科上,糊涂窗口确实存在发送端以及接收端两种类型,关于接收端糊涂窗口的命名存在一定的争议,我认为有可能是历史原因,当初命名的人并没有那么走心,目前还在考证。不过,个人认为 Nagle 最初解决的应该是接收端糊涂窗口问题,实际上他本人在提交的 RFC 上并没有提及到任何糊涂窗口的字眼,而是 the small-packet problem,而且从文中所述以及维基百科上的纳格算法来看,发送端发送的数据包小的原因并不是因为接收端的滑动窗口,更多的是发送端本身的问题。参考:1. 糊涂窗口-维基百科 2. 纳格算法-维基百科() 3. rfc896(https://www.ietf.org/rfc/rfc896.txt)
Allen()(作者)4 个月前
好了,再来谈谈发送数据慢的问题,发送者一个字节一个字节的发送数据,这其中不涉及任何滑动窗口的问题(从何而来的窗口综合症呢?),虽然这也造成了网络中大量的小报文,但是纠其原因并不因为是小窗口导致的,而是发送者自身的问题。所以将其称之为糊涂窗口问题,感觉有点强行关联的意思。 但是 Nagle 可以解决这样的问题,原理你已经知道了,就不再多说了。
Allen()(作者)4 个月前
常我们说对方的接收能力存在问题,每次通告小窗口,导致发送方每次发送小报文,造成恶性循环,这种称为sws. 我个人理解,数据发送慢并不能称为sws问题,尽管有相关书籍或博客称其为 sws,但实在难以将其和滑动窗口挂钩,这块可以成为一个可以讨论的点。所以这里我们主要讨论接收窗口的小的问题。 那么 Nagle 如何避免对方通告小窗口呢?主要是利用在接收到 ACK 这一空档期(网络时延+可能的 Delay ACK 时延,如果接收方开启了 Delay ACK 的话)给对方足够的时间处理数据,让对方扩大滑动窗口,也就是让方在尽可能长的空档期内,消费掉接收缓冲的数据。 从概率上讲,空档期越长,对方消费缓冲区的数据就越多,腾出的缓冲区空间就越大,因此返回的 ACK 中通告的滑动窗口就越大。 还有一种解决方案就是让接收者自己解决,如果自己的缓冲区小于一定的值(比如小于 1024 字节),就不应该通告小窗口给对方,而是通告对方接收窗口为 0,让对方不要在发数据过来了,等应用层消费掉一定量的数据后,再通告对方一个大窗口。关于这个细节,TCP 实现中有一个叫做持续定时器的机制配合使用。
徐欢欢℡¹³²⁶²⁸⁷⁷⁵⁸⁶4 个月前
我好像知道了,这个应该不是这么计算的。这个时间是进程收到tcp包的时间,所以两个时间差等于服务器的处理时间加上传送时间。假设传送时间固定那么这个时间的差值的相对大小就能够反应问题了。
你可能还喜欢
Redis 知识点整理
JavaTimo
1925·青年必读书——民国名流开具的书单
李烨
Java 集合底层原理剖析(List、Set、Map、Queue)
老牛
基于 Spring Boot 的线程池最佳实践
古拉里
Vue 一步一步搭建企业级后台管理系统
一只帅帅的猿
Spring Boot 面试指南(50 题)
axiya
微信扫描登录
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!
入群与作者交流×
扫码后回复关键字 入群
Chat·作者交流群
入群码
该二维码永久有效