TCP协议

Posted 起床oO

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TCP协议相关的知识,希望对你有一定的参考价值。

TCP在网络OSI的七层模型中的第四层-Transport层,IP在第三层--Network层,ARP在第二层--DataLink层,在第二层上的数据我们将Frame,在第三层上的数据叫Packet,第四层的数据叫Segment。

首先,我们需要知道,我们程序的数据首先会打到TCP的Segment中,然后TCP的Segment会打到IP的Packet中,然后再打到以太网的Ethernet的Frame中,传到对端后,各个层解析自己的协议,然后把数据交给更高层的协议处理。

TCP头格式

注意:

  • TCP的包是没有IP地址的,那是IP层上的事。但是有源端口和目标端口。
  • 一个TCP连接需要四个元祖来表示是同一个连接(src_ip,src_port,dst_ip,dst_port)准确来说是五元组,还有一个是协议,但因为这里只是说TCP协议,所以只说四元组。
  • Sequence Number是包的序号,用来解决网络包乱序(reordering)问题。
  • Acknowledgement Number就是ACK--用于确认收到,用来解决不丢包的问题。
  • Window又叫Advertised-Window,也就是著名的滑动窗口,用于解决流控的。
  • TCP Flag,也就是包的类型,主要用于操控TCP的状态机的。

TCP状态机

网络上的传输是没有连接的,包括TCP也是一样的。而TCP所谓的“连接”,其实只不过是在通讯的双方维护一个“连接状态”,让它看上去好像有连接一样。所以,TCP的状态变换是非常重要的。

下面是:“TCP协议的状态机”和"TCP建连接",“TCP断连接”,“传数据”的对照图:

                      

 为什么建连接要3次握手,断连接需要4次挥手?

  • 对于建连接的3次握手,主要是要初始化Sequence Number的初始值。通信双方要互相通知对方自己的初始化的Sequence Number(缩写为ISN:Inital Sequence Number)--所以叫SYN,全称 Synchronize Sequence Numbers。也就是图中的x和y。这个号码要作为以后的数据通信的序号,以保证应用层接收到的数据不会因为网络上的传输的问题而乱序(TCP会用这个序号来拼接数据)。
  • 对于断开连接的4次挥手,其实仔细看是2次,因为TCP是全双工的,所以,发送方和接收方都需要FIN和ACK,只不过,有一方是被动的,所以看上去就成了所谓的4次挥手,如果两边同时断开连接,那就会进入到CLOSING状态,然后到达TIME_WAIT状态。下图是双方同时断连接的示意图:

另外,还有几个事情需要注意一下:

  • 关于建连接时SYN超时。试想一下,如果server端接到了client发的SYN后回了SYN-ACK后client掉线了,server端没有收到client回来的ACK,那么,这个连接处于一个中间状态,即没成功,也没失败。于是,server端如果在一定时间没有收到回复,TCP会重发SYN-ACK,在Linux下,默认的重试次数为5次。
  • 关于SYN Flood攻击.一些恶意的人就为此制造了SYN Flood攻击--给服务器发一个SYN后,就下线了,于是服务器需要经历重传和等待之后最终才会断开连接,这样攻击者就可以把服务器的SYN连接队列耗尽,让正常的连接请求不能处理,于是Linux下给了一个叫tcp_syncookies的参数来应对这个是--当SYN队列满了后,TCP会通过源地址端口,目标地址端口和时间戳打造一个特别的Sequence Number发回去(又叫cookie),如果是攻击者则不会有响应,如果是正常连接,则会把这个SYN Cookie发回来,然后服务端可以通过cookie建立连接(即使你不在SYN队列中)。请注意,请先千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为synccookies是妥协版的TCP协议,并不严谨,对于正常的请求,你应该调整三个TCP参数可供你选择,第一个是tcp_synack_retries可以用他来减少重试次数;第二个是tcp_max_syn_backlog,可以增大SYN连接数;第三个是tcp_abort_on_overflow处理不过来干脆就直接拒绝连接了。
  • 关于ISN的初始化。ISN是不能hard code的,不然会出问题,RFC793中说,ISN会和一个假的时钟绑在一起,这个时钟会在每4微妙对ISN做加1操作,直到超过2^32,又从0开始,这样一个ISN的周期大约是4.55个小时。因为我们假设我们的TCP Segment在网络上的存货时间不会超过Maximum Segment Lifetime(缩写为MSL),所以只要MSL的值小于4.55小时,那么,就不会重用到ISN。
  • 关于MSL和TIME_WAIT。通过上面的ISN描述,在TCP的状态图中,从TIME_WAIT状态到CLOSED状态,有一个超时设置,这个超时设置是2*MSL(RFC793定义MSL为2分钟,Linux设置成了30s)为什么要设置TIME_WAIT状态,为什么不直接转成CLOSED状态呢?主要有两个原因1):TIME_WAIT确保有足够的时间让对端接收到ACK,如果被动关闭的那方没有收到ACK,就会触发被动端重发FIN,依赖一区刚好是2个MSL,2):有足够的时间让这个连接不会跟后面的连接混在一起(你要知道,有些自作主张的路由器会缓存IP数据包,如果连接被重用了,那么这些延迟的包就有可能会跟新连接混在一起)

数据传输过程中的Sequence Number

下图展现的是SeqNum是怎么变的:

SeqNum的增加是和传输的字节数相关的。

注意:如果你用Wireshark抓包程序看3次握手,你会发现SeqNum总是为0,不是这样的,Wireshark为了显示更友好,使用了Relative SeqNum--相对序号,你只要再右键惨淡中的protocol preference中取消掉就可以看到"Absolute SeqNum"了。

TCP重传机制

TCP要保证所有的数据包都可以到达,所以必需要有重传机制。

注意,接收端给发送端的ACK确认只会确认最后一个连续的包,比如发送端发送了1,2,3,4,5一共5份数据,接收端收到了1,2,于是回ack 3(表明接收端下一个需要的包是3号数据包),然后收到了4(注意此时3没有收到),此时TCP该怎么办呢,我们要知道,因为正如前面所说的,SeqNum和Ack是以字节数为单位,所以ack的时候,不能跳着确认,只能确认最大的连续收到的包,不然发送端就以为之前的都收到了。也就是说这种情况下,接收端会一直回复ack 3,知道3号包收到位置。

超时重传机制

一种是不回ack,死等3号包,当发送方发现收不到3的ack超时后,会重传3。一旦接收方收到3后,会ack回5,意味着3,4号包都收到了,我下一个需要的包是5号包。

但是这种方式会有比较严重的问题,那就是因为要死等3号包,所以导致4和5即便已经收到了,而发送方也完全不知道发生了什么事,因为没有收到3号包的ack,所以发送方可能会悲观的任务,4号包和5号包也丢失了,导致4号包和5号包也重传。

对此,有两种选择:

一种仅重传timeout的包,也就是第3份数据。

一种是重传timeout后所有的数据,也就是3,4,5这3份数据。

这两种方式有好也有不好。第一种会节省带宽,但是慢,第二种会快一点,但是浪费带宽,也可能会有无用功。但总体来说都不好。因为都在等timeout,timeout可能会很长。

快速重传机制

TCP引入一种叫Fast Retransmit的算法,不以时间驱动,而以数据驱动重传。也就是说,如果包没有连续到达,就ack最后那个可能你丢了的包,如果发送方连续收到3次相同的ack,就重传。Fast Retransmit的好处就是不用等timeout了再重传。

比如:如果发送方发出了1,2,3,4,5份数据,第一份数据先到了,于是ack就回2,结果2因为某些原因没有收到,3到达了,于是还是ack回2,后面的4和5都到了,但是还是ack回2,因为2还是没有收到,于是发送端收到了3个ack=2的确认,知道了2还没有收到,于是马上重传2,然后接收端收到了2,此时因为3,4,5都收到了,于是ack回6,示意图如下:

Fast Retransmit只解决了一个问题,就是timeout的问题,它依然面临一个艰难的选择,就是,重传之前的一个还是重传所有的问题。对于上面的实例来说,是重传#2,还是重传#2,#3,#4,#5呢,因为发送端并不清楚这连续的3个ack(2)是谁传回来的,也许发送端发了20份数据,是#6,#10,#20传回来的呢。这样,发送端很有可能要重传从2到20的这堆数据(这就是某些TCP的实际的实现)。可见,这是一把双刃剑。

SACK方法

另一种更好的方式叫 Selective Acknowledgment (SACK),这种方式要在TCP头里加一个叫SACK的从西,ACK还是Fast Retransmit的ACK,SACK是汇报收到的数据碎版。参看下图:

这样,在发送端就可以根据回传的SACK来知道哪些数据到了,哪些没到,于是就优化了Fast Retransmit算法。当然,这个协议需要两边都支持,在Linux下,可以通过tcp_sack参数打开这个功能(Linux 2.4后默认打开)

这里还需要注意一个问题--接收方Reneging,所谓Reneging的意思就是接收方有权把已经报给发送端SACK里的数据给丢了。这样做是不被鼓励的,因为这个事会吧问题复杂化,但是接收方这么做可能会有些极端的情况,比如要把内存给别的更重要的东西。所以,发送方也不能完全依赖SACK,还是要依赖ACK,并维护Time-Out,如果后续的ACK没有增长,那么还是要把SACK的东西重传,另外接收端永远不能把SACK的包标记为Ack。

以上是关于TCP协议的主要内容,如果未能解决你的问题,请参考以下文章

分析tcp协议原理

TCP/IP协议

什么是TCP/IP协议?

TCP/IP协议是啥?

Labview(2)之TCP协议

TCP/IP协议