关于TCP协议的大部分,面试常问的几点都在这理里了

精选30+云产品,助力企业轻松上云!>>> hot3.png

点击蓝色“大数据每日哔哔”关注我

加个“星标”,第一时间获取大数据架构,实战经验




由于面试中经常会问到TCP协议的一些细节,工作中使用的场景也很多,比如三次握手的详细过程、断开连接的过程、滑动窗口、拥塞控制、理解RPC远程调用的网络传输等方面的内容,因此这里就整理下。


1. 传输层协议


传输层协议有哪些?


传输层主要是包含两个协议,即TCP和UDP协议,其中

UDP (User Datagram Protocol) :基于UDP协议的上层协议包括 DNS,RIP,DHCP,NFS等。传送数据前不需要先建立连接。
TCP (Transmission Control Protocol):基于TCP协议的上层协议包括SMTP,Telnet,HTTP,FTP等。TCP是面向连接的。


由于传输层使用IP+端口号使得不同主机上的进程可以通信,也就是Socket,如192.168.1.1:8080。端口号是16位,最大为65535。其中,0-1023是保留端口号,如常见的有FTP 21, Telnet 23,SMTP 25, DNS 53, HTTP 80等。



2 . UDP协议简介


UDP协议非常的简单,仅仅在IP协议上增加了一点点功能。主要特点是:

  1. 无连接。

  2. 尽最大努力交付。

  3. 面向报文。对应用层交下来报文不拆分也不合并,直接添加首部交给IP层。因此若报文太长,就会让IP传输很长时间,若报文太短,会使得大量空间浪费在各类协议首部,降低传输效率。

  4. 支持1对1,1对多,多对多。

  5. 没有拥塞控制。

  6. 报文首部开小,只有8个字节。包含源端口号、目的端口号、长度和校验和。



3. TCP概述


TCP协议的特点是:

  1. 面向连接

  2. 点对点(一对一)

  3. 可靠交付

  4. 面向字节流,也就是说仅仅把上层协议传递过来的数据当成字节传输。
    为了实现TCP上述的特点,TCP协议需要解决的是面向连接(建立连接和关闭连接的方式)、可靠传输(错误确认和重传)、流量控制(发送方和接收方的传输速率协调)、拥塞控制四个方面。



4. TCP协议首部格式


TCP协议首部最小长度是20字节,首部有一个长度可变的选项部分,最大40字节,所以TCP首部长度是20-60字节大小。具体如图:

c1b70145c46ac89d5618cff433ba754f097.png


选取部分字段说明:
序号:TCP传输的时候每一个字节都按顺序编号;协议中的序号是本报文段所发送数据第一个字节的序号。序号也用于建立和结束连接时候使用。
确认号:用于可靠传输中,返回确认报文序号。
数据偏移:指出数据段在报文中开始的位置。
窗口:可靠连接和流量控制中所用到的窗口大小。

上图中有六个控制位,对于建立和结束连接非常关键,解释如下:

  1. URG(Urgent):紧急字段,可以让该报文不按报文顺序优先被处理。比如用户突然终止传输关闭连接。

  2. ACK(Acknowledge):所有建立连接后传送的报文ACK必须为1.

  3. PSH(Push):发送方讲该报文推送向前,可以不用等缓存填满先提交给应用程序。

  4. RST(Reset):连接出现严重差错时候设为1,重新建立连接。也可用于拒绝建立连接。

  5. SYN(Synchronize):建立连接时候的同步标志。SYN=1而ACK=0时表示建立连接请求。

  6. FIN(Finish):终止时标志位。

另外,在选项中有这么几种选择:

  1. 最大报文长度MSS(Maxium Segment Size),指的是一个TCP报文数据段的最大长度。要尽可能大一些但是又不需要IP拆分。推荐是536字节,这样真个TCP报文长度是 536+20 = 556字节。

  2. 窗口扩大选项。可用于控制传输窗口大小。

  3. 时间戳。非常有用。可以用于 1)计算往返时间RTT 2)区分重复报文。因为报文的序号只能是2^32-1个,所以很容易就重复了,加上时间戳可以进行区分。



5. T CP协议的建立连接过程(三次握手)


著名的三次握手协议,一图胜万语。

fb17bf59e15fdfd84c96cb68f2de3f99f49.png


对上图的说明:
SYN和ACK已经说过了。seq就是首部中的序号字段,图中x和y都是随机生成的,然后收到后返回确认会将其+1.注意发送方和接收方的状态变化如下:

发送方: CLOSED-->SYN-SENT-->ESTABLISHED
接收方: CLOSED-->LISTEN-->SYN_RECEIVED-->ESTABLISHED

为什么需要三次握手?主要是为了防止“已失效的连接请求”。加入只要两次握手,即A发送请求B返回确认就可以建立连接。可能会出现以下情况:比如,A发送的第一个连接请求并未丢失,而是延滞了,此时A已经放弃了建立连接,但是B又最终收到了,于是返回ACK给A,这样就错误的建立了连接。

六 TCP协议关闭连接过程(四次握手)

释放连接的过程也见下图:

1f98d24b8f16d85be43da3143352189a890.png


对上图的说明:FIN、ACK字段之前已经讲过。seq是序列号,图中每一个新的字母都表示随机生成。释放连接的状态变化:
发送方:ESTABLISHED-->FIN-WAIT_1-->FIN-WAIT_2-->TIME-WAIT-->CLOSED
接收方:ESTABLISHED-->CLOSE-->WAIT-->LAST-ACT-->CLOSED

注意,释放连接包含两个来回。前两次握手代表发送方不再传输数据了。后两次握手代表接收方不再传输数据了,因为TCP是全双工通信,二者是可以同时发送消息和接受消息的。所以图中B的CLOSE-WAIT阶段,仍然可以传输数据。


为什么A在发送确认后还有TIME-WAIT的阶段?有两个理由:

  1. A发送的最后一个ACK必须到达B。如果B没有收到该ACK,可能会再次发送FIN+ACK。如果此时A关闭了,B就不可能收到ACK了,也就无法正常关闭。

  2. 同三次握手一样,A等待一段时间,可以上网络中本次连接的延滞的请求都发送到位,然后再关闭连接,这样网络里面就不会再剩下本次连接的请求了。


TIME-WAIT设置为多久?更具上述分析,一般会把TIME-WAIT时间设置为2MSL,MSL代表最长报文寿命(Maximum Segment Lifetime)。也就是说,如果一段报文最长寿命为2分钟,会让A等待4分钟后再关闭。



7. TCP协议可靠传输的实现


基本原理 


考虑A发送数据到B接受的情况。记报文为M。
停止等待协议:A每发送完一个报文M,就等候B对其确认;收到确认后继续发送。A设置超时重传机制。因此这种机制也成为自动重传请求ARQ(Automatic Repeat reQuest)。


连续ARQ协议/窗口滑动协议 


显然,每次只发送一个报文然后等待确认效率太低。所以可以约定每次发送多个报文,然后采用累积确认的方式。B对按序到达的最后一个分组发送确认。如果中间发生丢失包的情况,A需要回退到确认的报文重新发送。如图所示。

3074a7ca7ba4c6915683dd525682340a315.png


说明一下:A的发送窗口大小是根据B接受窗口设置的。也就是说A发送的报文速度不能超过B处理报文的速度。


TCP中对于超时重传时间的选择是根据平均往返时间RTT来计算的。也就是说,如果A超过一个报文平均往返时间没有收到确认,就会重新发送报文。



8. TCP协议流量控制


流量控制,简单来说就是不能发送的太快,以免处理不完,也不能发送的太慢,以免浪费资源。TCP协议中,建立连接之时,B会告诉A自己接受窗口的大小,A的窗口大小不会超过这个大小。



传输过程中,B会根据自己数据缓存的情况给A返回自己的窗口大小,例如,刚开始发送数据时,B的缓冲区为空,设置窗口大小为300,A开始发送;但是由于A发送的太快,B缓冲区渐渐变满,就会将接受窗口的大小设为100;如果B的缓冲区满了,还可能将窗口大小设为0,A就停止发送,直到B重新发送了一个窗口大小。



9. TCP协议拥塞控制


慢开始、拥塞避免、快重传、快恢复

拥塞控制发生在网络中负载太大,比如路由器IP包队列堆满了,就会丢弃尾部的包,从而导致TCP层数据的丢失。拥塞控制就是要避免网络数据量太大导致传输效率、速度降低。


常见的TCP拥塞控制方法包括四种:

  1. 慢开始

  2. 拥塞避免

  3. 快重传

  4. 快恢复


慢开始是指,TCP开始建立连接发送数据后,每次发送的报文段数从1开始。不能一开始就发送大量的报文段。如果网络畅通,发送方每个数据往返来回就把发送报文的数据量增加一倍。注意,这里的报文数据量指的就是窗口大小
这样指数级会导致发送窗口快速增长。当超过一定值时候,就可能导致网络拥塞了,这个值被称为慢开始门限ssthresh。超过ssthresh后就采取拥塞避免的算法。变为发送窗口每次增长1.


如果A超过一定时间没有收到B发来的确认,说明报文丢失了,网络拥塞出现,此时将窗口大小设置为1,并将ssthresh设置为出现拥塞时窗口大小的一半。重新进行慢开始算法。这个过程称为AIMD(加法增大乘法减小)。

d2f1d202935cabb9a0d677b44ff340a4dbf.png


快重传是指,接收方B每收到一个失序的报文段(以为之前有报文段拥塞了)就立即发出重复确认。发送方如果连续收到三个重复确认就立即重传该报文段,而无需等候为重传计时器。如下图:

96dcb2908d63cc06254cdf7624ae6865171.png

快重传和快恢复配合使用。如果发送方连续收到三次重复确认时,就执行“乘法减小”策略。但是不同之处在于,此时不再将窗口设置为1(慢开始算法),而是执行拥塞避免算法。如下图:


0e0de70297094d3c2a36887f7ce0ed01e85.png


增加了拥塞控制算法后,TCP协议中发送方窗口大小设置为:

Min[拥塞窗口,接收方窗口]


随机早期检测RED


对TCP拥塞控制影响最大的是路由器的分组丢弃策略。路由器按照先进先出的原则发包。当队列满了之后,就会将超出队列的包一起丢弃。
由于一个路由器的包是来自于不同TCP协议客户端,这些发送方会同时发现丢包了,于是执行拥塞算法,此时网络中流量骤然下降,待网络恢复后,通信量又会突然增大。


为了避免这种情况出现,可以让路游戏采用随机早期检测算法RED(Random Early Detection)。方法很简单,设定一个队列最小阈限THmin和队列最大阈限THmax。当队列长度<THmin时,正常发包;当队列长度介于THmin和THmax之间时,按照一定概率p随机丢包;当队列长度大于THmax时,将新到达的包丢掉。概率p可以随着队列长度增加逐渐从0增加到1.THmax一般设置为THmin的两倍。通过这种算法,就可以避免开始所述的网路流量突然增大和突然缩小的情况。



10. 参考文献


《计算机网络(第五版)》谢希仁,文中所有内容和配图均来自本书第五章


往期推荐

【干货】趣头条基于 Flink+ClickHouse 构建实时数据分析平台

干货 | 有赞数据仓库实践之路

干货 | 携程机票数据仓库建设之路

干货 | 携程Hadoop跨机房架构实践




专注大数据技术、架构、实战

关注我,带你不同角度看数据架构


96f57c93f0fe2008c489444af50c749fa0a.jpg

本文分享自微信公众号 - 大数据每日哔哔(bb-bigdata)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值