TCP协议执行过程

传输层

1. 网络层帮我们定位计算机位置后，之后就会接入应用程序，首先我们能够开始多个应用程序，也就是说一个ip是为多个应用程序服务，那如何区别应用程序的不同——端口能帮我们解决多个应用程序的情况下的数据传输。
2. 所以传输的层的功能是建立在端口与端口之间的通信，那么就要提到TCP协议和UDP协议了，这两种协议都用于数据的传输

TCP协议

1. TCP协议是面向连接的全双工的可靠传输协议，TCP报文段没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常TCP报文段的长度不会超过IP报文段的长度，以确保单个TCP报文段不必再分割。

TCP协议头

1. 协议头字段说明：
   • 源端口号：TCP报文段发送方的端口号信息
   • 目标端口号：TCP报文段接收方的端口号信息
   • 序列号：在TCP连接初始阶段是由主机随机产生的序列号（ISN, Initial Sequence Number），但是序列号并非不会改变序列号会随着主机之间的数据发送接收而发生改变，如果是在没有数据的情况下，每一次的请求发送都会使序列号+1，而如果在发送数据的情况下，则是按照发送字节的数量进行偏移，如发送了一个1024字节的报文段时，序列号就会变成当前序列号+1024。
   • 确认序列号：确认序列号是接收端接收到报文段后响应的序列号，用于发送端对数据的验证，每次返回的确认序列号都是发送端的序列号+1。
   • 头部长度：当前报文段的协议头所占用的长度；其长度为4bit，4bit代表的整数为15，15*32bit，则代表头部当前最大长度为60字节。
   • 窗口大小：该选项是TCP的一种控制流量的手段，用于接收端对接收缓存大小的界定，这样发送端在发送数据时就会按照界定的大小进行报文段的传输。
   • 校验和：
     • 由报文段发送端进行填充，用于接收端tcp报文段进行校验的值，而且在发送端在产生校验时会在tcp中生成伪头部，伪头部中包含了源IP、目标IP、传输层协议号、tcp长度；
     • 计算时发送方首先会将校验和置为0，之后将tcp包括伪头部、协议头、数据这三块的每16位进行二进制求和，但是要注意的是在传输数据时不可能数据的长度不可能都是16位的倍数，所以在最后一个位置上可能出现奇数位，这样会在该奇数位的右边填充一个0以做计算，但不参与数据传输。
     • 在整个TCP二进制求和时会出现求出的和进位的情况，这样会将进位的高位与低位相加，直到没有进位为止。最后对和进行取反放入校验和的字段中。
     • 接收方接收到tcp报文段后也是将tcp进行二进制求和，溢出的部分对高位进行叠加，如果全是1则验证通过否则丢弃
   • 紧急指针：存放的是一个正的偏移量，该偏移量加上当前的报文的序列号将得到紧急数据的最后一个字节的序号。
   • 选项：选项是一个可变长的可选信息标注，选项的最大长度不超过40字节，多个选项可以同时存在。
     • 选项内部字段：
       • kind：该字段标注该选项的类型，占用1字节；
       • len：标注该选项的长度，不是每个选项都存在该字段，占用1字节；
       • info：选项信息，不是每个选项都存在该字段。
     • 选项列表：
       • kind=0：EOP选项，为选项信息结束的填充；
       • kind=1：NOP选项，为选项信息不足4字节整数倍时的填充；
       • kind=2，len=4，info为2字节最大长度：MSS选项，用于在同步报文阶段协商最大报文段长度，一般而言其长度为MTU-TCP协议头长度-IP协议头长度；
       • kind=3 ，len=3，info为1字节位移数：窗口扩大选项(Wsopt)，需要在SYN报文段进行协商，协商完成才会进行使用；上面的窗口大小字段标注了最大的窗口大小也就是最大不超过65535，但是TCP实际能接收的数据远不止这些，所以通过窗口扩大因子来对窗口大小进行进一步的描述，还需要注意的是，就如窗口大小字段一样，扩大因子只会在同步报文段时进行协商，一旦确定后就不会更改；设窗口大小为x，扩大因子为y，则实际窗口大小为：x*2^y,实际就是x右移y位；其扩大因子的范围位0~14。
       • kind=4，length=2：是否开启选择性确认（Selective Acknowledgment，SACK）选项，只会出现在SYN报文段中。
       • kind=5：SACK实际工作的选项。
       • kind=8，len=10，info总长度8字节包含4字节时间戳(TSval)和4字节的时间戳回显应答(TSecr)：时间戳选项(TSopt)。
         • 开启时间戳选项需要主动发起连接一方在SYN报文段中指定选项之后，在接收方接收到报文段后，才会在以后的报文段中进行设置，在4.4BSD的设计中启动时会将时间戳始终设置为0，并且每间隔500ms时钟加1；时间戳选项的值会在发送方和接收方各自进行维护，发送方发送分组时会填充TSval，接收方发送ACK时会将发送方的时间戳填充到TSecr中，并在TSval中填充自己的时间戳，就如同seq一样。
           • 时间戳选项应用一：对RTT的测量
             • 开启选项后TCP会使用时间戳字段来测量RTT，而在接收方会维护两个变量值：TS.Recent用于填充ACK的回显时间戳，Last.ACK.sent用于记录最后一次发送ACK报文段的确认序号，所以在RTT的测量中实际使用到的只有发送方的时间戳，以下是对RTT测量的说明：
               • 如果接收方打开延时确认，接收方在接收到报文段时不会马上返回ACK，哪怕在延时确认期间又有数据报文段达到，最后发送的时间戳也会是第一段报文的时间戳，因为RTT的测量需要考虑延时确认的时间。
               • 如果发送报文段时发生失序，而此时发送方依然会发送报文段直至窗口填满，而接收方可能在中途发送失序的ACK确认，在此情况下会发哦是那个最新一段数据报文段的时间戳值，因为高估RTT比低估更好。
               • 如果接收方接收到的第一份报文段虽然在窗口范围内但是却是失序的，证明前面的报文段已经丢失，当丢失的报文段到达时，丢失重传报文段的时间戳将被回显，因为RTT的测量如果包含超时重传的时间，这将导致RTT的测量过高。
           • 时间戳选项应用二：PAWS算法（防止序号回绕）
             • 时间戳选项可以用于便面长肥管道中出现的序号回绕而引发的问题，也就是当接收方收到来自发送方的时间戳时，如果该时间戳小于接收方收到其他分则的时间戳时，接收方就会将该分组丢弃。
   • 标志位：
     • URG：指示当前发送的数据存在紧急数据。
     • ACK：指示当前报文段的确认序列号有效。
     • PSH：指示接收方收到数据后尽快将数据交给应用程序。
     • RST：重建连接。
     • SYN：指示当前报文段为一个新建连接请求。
     • FIN：指示当前主机已经执行完成发送任务。

TCP的连接与关闭

1. 注：下面连接或关闭使用到序列号为R的，皆代表为不能准确获取的序列号。
2. TCP协议三次握手
   • TCP协议的三次握手产生首次连接时，通过相互的验证保证连接的成功性
     
   • 这里我们约定主机A和主机Ｂ进行连接：
     • 第一次握手： 由主机Ａ主动的开启连接，在第一次握手时主机Ａ会发送SYN同步报文段（SYN=1,seq=J），该报文段表示需要新建连接，然后将A的端口数据填充后发送连接，此时主机A进入SYN-SENT（请求连接）阶段。
     • 第二次握手： 主机Ｂ接收到SYN报文段后，知道主机A需要建立连接。主机B会对主机A的SYN报文段进行响应发送ACK确认报文段（SYN=1,ACK=1,seq=K,ack=J+1），此时主机B进入SYN_RECEIVED（连接接收）阶段。
     • 第三次握手： 主机A接收到ACK确认报文段后，证明主机B连接正常，主机A也需要发送ACK确认报文段(ACK=1,seq=R,ack=K+1)，此时主机A进入ESTABLISHED（连接建立）阶段；主机B在接收到连接后检验后也进入ESTABLISHED（连接建立）阶段。此时主机A和主机B的连接通道已建立。
3. TCP协议四次挥手
   继续上面主机A和主机B的用例：
   
   • 第一次挥手： 首先主机A提出需要关闭连接向主机B发送FIN报文段（FIN=1,seq=M），此时主机A进入FIN_WAIT1（终止等待1）阶段。
   • 第二次挥手：
     • 主机B接收到连接后，对协议进行解析，发现标志位FIN被标志为1，知道主机A请求关闭连接；主机B会将主机A发送ACK确认报文段（ACK=1,seq=X,ack=M+1）。此时主机B进入CLOSE-WAIT（关闭等待）阶段。
     • 主机A接收的ACK报文进行确认，此时主机A进入进入FIN-WAIT2（终止等待2）阶段，该阶段内主机Ａ只能接收报文段不能发送报文段。
   • 第三次挥手： 在此之前如果主机B还有报文发送到主机A则继续发送，发送完成或无数据报需要发送的情况主机B才会发送FIN报文段（FIN=1，ACK=1，seq=R，ack=M+1），之后进入LAST-ACK（最终确认）阶段。
   • 第四次挥手：
     • 主机Ａ收到了FIN报文段后，主机A会发送最后一次ACK确认报文段，在此之后主机A会进入TIME_WAIT（定时等待）阶段， 等待2MSL后客户端彻底关闭(MSL为报文段最大生存时间，可能是30秒、1分钟、2分钟)。等待的原因是因为如果因为某些原因主机B没有收到报文段，主机B处于的LAST-ACK阶段会在超时后重新发送FIN报文段，这样就不会因为主机A的关闭而接收不到报文段；2MSL的等待也保证了不会因为主机A连接关闭后，重新发送连接时再次连接到之前的连接上，这样新的连接也可能会接收到属于上一次的数据。
     • 主机B接收到报文段后会直接关闭连接。
4. TCP连接状态：
   • 全关闭：经历完整的四次挥手后连接就会进入全关闭；
   • 半关闭：该状态发生在四次挥手时，当主动关闭连接的一方进入IN_WAIT2状态时连接就进入了半关闭；
   • 半打开：当有一方出现异常关闭时，另外一方并不知情时，此时连接处于半打开状态。
   • 半连接：该状态发生在建立连接时，当主动发起建立的一方没有向另一方发送ACK确认时，另外一方一直处于SYN_RCVD状态。

TCP数据流

1. TCP交互数据流
   • TCP交互数据流一般用于交互比较高的应用中，如Rlogin、Telnet等要求回显速率的应用会使用该数据流
   • 延时确认（ACK捎带）：接收方收到TCP报文段后，会等待200ms，如果在此间有数据需要响应则直接将数据跟随ACK确认报文进行发送，如果超出200ms都没有需要发送的报文数据则直接发送确认报文段。
2. TCP成块数据流
   • 相比于交互数据流，成块数据流适合大数据量的传输，如HTTP、FTP等都使用的是成块数据流
   • 滑动窗口协议：
     • 依照交互数据流的方式，发送方发送数据报后需要收到ACK确认数据报文才能发送下一份数据报，这样的好处是不会出现乱序和丢包，但是其吞吐量就变小了。滑动窗口协议的出现解决了该问题。
     • 窗口大小：了解滑动窗口协议钱先说说窗口大小，Socket API允许应用程序指定发送和接收的缓冲区大小(这里的缓冲区大小就是所谓的窗口大小,所以发送和接收都有一个窗口)，一般而言默认的发送和接收的缓冲区大小为4096字节，而当发送和接收的缓冲区大小增加到16384个字节可以增加约40%左右的吞吐量。
     • 滑动窗口
       
       • 上图我们看到一个滑动窗口的缩略图，在滑动窗口协议虽然双方都有窗口大小，但是窗口的滑动由发送方来调控，以上图作为演示我们发送11段的报文数据，我们的发送端窗口有6个报文段大小，注意的是滑动窗口并不一定就发送全窗口的报文段，并且其窗口的移动是相对于接收方确认报文的确认号。
         • 我们首先发送了1~3段报文得到再得到确认后，窗口右移；
         • 之后我们再发送4~6段报文，但是发送后，未得到确认，所以窗口是保持不动的；
         • 7~9段报文准备发送。
       • 滑动窗口的大小变化
         • 窗口合拢：窗口左边沿向右边沿靠近，此时窗口大小变小，该过程发生在窗口数据被发送和确认时。
         • 窗口张开：窗口右边沿向右移动，该过程发生在接收方收到数据报文确认并释放TCP缓存后。
         • 窗口收缩：窗口右边沿向左移动，Host Requirements RFC强烈建议不要使用这种方式。
     • 关于滑动窗口运作原理上面已经做了描述，滑动窗口模式在LAN环境中做数据传输是完全没有问题的，但是对于WAN中来说TCP分组会途径许多的路由器，而路由器可能会对分组进行缓存，直到存储器用尽，那这样就会使吞吐量降低，那慢启动就实际上是帮我们在WAN上传输分组上找到最合适的发送频率（如果接收方通告窗口大于拥塞窗口，则发送窗口等于拥塞窗口，否则发送窗口等于接收方通告窗口），在下图中展示慢启动以及对慢启动一系列引发的问题进行优化的算法：
       
   • 慢启动
     • 拥塞窗口（cwnd）：拥塞窗口是由慢启动通过发送TCP分组以及收到的确认报文一步一步计算出来的，首先慢启动的原理是在连接打开发送数据报文的时候 ，cwnd值为1个报文段大小,这时会首先发送一份报文；如果报文得到确认，cwnd值变为2个报文段大小，此时会发送两份数据报文，如果发送出去的两份报文也得到确认那么cwnd值变为4个报文段大小，此时会发送四份数据报文，以此类推。所以cwnd的增长是成指数型的方式进行增长的。
     • 接收方通告窗口(rwnd)：除了拥塞窗口会影响滑动窗口外，接收方的通告窗口也会影响滑动窗口，接收通告窗口告知发送方接收方当前还能接收多大的数据报，在发送数据报时如果接收方通告窗口大小小于拥塞窗口，发送方当按照接收窗口的限定进行报文发送，当接收通告窗口为0时则不发送数据报文；拥塞窗口是发送方对流量的控制，而接收方通告窗口则是接收方对流量控制的手段。
   • 拥塞避免算法
     • 上面我们描述了cwnd的指数增长，但是如果任其无止境的增长，那最终的结果也会适得其反，所以需要对cwnd的增长加以控制，所以就引出了拥塞避免算法，该算法通过ssthresh的值来判断对cwnd的增长控制。
       • 在连接初始，我们直到cwnd被置为1个报文段大小，而ssthreh会被置为任意大的字节（因为一般发生拥塞ssthreh就会被重置），此时会依照慢启动的方式进行，但是当cwnd字节数大于ssthreh时，此时会进入拥塞避免，处于拥塞避免状态的连接，发送方每接收到数据确认报文时，cwnd就会在原基础上加1个报文段大小，而非按慢启动的指数型增长。
       • 当拥塞发生时（超时或重复确认），此时ssthresh会被设置为当前窗口的一半（取cwnd和接收方通过窗口大小中的最小值来计算，但最小为2个报文段的大小）。如果是因为超时引起的拥塞，则cwnd被设置为1个报文段大小，进入慢启动。
3. Nagle算法：
   • 该算法指出当前TCP的连接上只能有一个未被确认的小分组(不满一个满报文段的报文段或者是不满一个接收方通告的报文段)，在该小分组没有确认前，其他小分组不能发送。这样的好处是确认的越快，数据发送的就越快，但是对于那种需要无延时的报文发送时，Nagle显然并不适用。
   • 可以通过Socket API的TCP_NODELAY选项关闭该算法。

TCP四大定时器

1. 超时重传定时器（参阅：RFC[2988]）
   • 往返时间（RRT）
     • RRT是发送方向接收方发送一次数据报文到收到确认报文的时间，值得注意的是RRT会总是500ms 的倍数，其内部有一个滴答计时，每一个滴答为500ms，当经过了一个滴答后，当前时间就属于下一个滴答计时范围，所以按滴答的计时就会根据当前从属于的滴答*500ms，得到一个RRT，而且当一个发送TCP分组开启定时器时，在该TCP分组未得到确认之前不会再开启一个RRT测量定时器。
   • 超时重传时间（RTO）
     • 超时重传时间会根据RRT的时间随之改变，因为在网络传输中其传输的效率会影响到RRT，从而如果RTO过小会造成发送端误以为数据报的丢失，而过大则会造成过了很长时间才发现数据已经丢失，造成吞吐量的降低，所以需要RTO根据数据传输速率的变化随之而变，才能在不同网络的传输上达到吞吐量最大化的目的。
     • RTO取值规则
       • 在连接初始化阶段发送方将RTO的值初始化为3s。
       • 再计算RTO的值之前需要了解两个变量：SRTT （平滑环回时间）和RTTVAR（环回时间变量），发送方需要一直维护这两个变量，并且会使用到TCP一个最小时钟间隔G，（在OS中一般还会设置一个最大时钟间隔，当RTO超过该时钟间隔后将不在数据报重发）
         • 当第一次测量到RTT的值时，发送方会根据以下规则维护SRTT和RTTVAR
           • SRTT=RTT
           • RTTVAR=RTT/2
           • RTO=SRTT+MAX（G,K*RTTVAR）,变量K为4 ，当K*RTTVAR<G时，取G值参与计算，所以哪怕RTT值很小，RTO的最小值也会比较固定。
         • 当非第一次测量到RTT的值时，发送会更改维护规则
           • SRTT=(1-alpha)*SRTT+alpha*RTT，其中增量alpha=1/8
           • RTTVAR=(1-beta)*RTTVAR+beta*|SRTT-RTT|，其中差值增量beta=1/4
           • RTO=SRTT+max(G,K*RTTVAR)
       • 以上计算方式中我们看到包括变量K、增量alpha、差值增量beta都是2的指数倍。这样在计算时都可以通过位移进行计算。
     • RTO的维护规则
       • 每当发送一次数据报文，如果超时重发定时器没有开启，则开启该定时器，并在RTO秒后超时；
       • 每当收到数据报的确认报文后，就关闭该超时重发定时器；
       • 当接收到一个ACK确认的新的数据时，重新启动定时器，使得其在RTO秒后超时，当定时器超时将重发最早尚未被接收方确认的数据报。
       • 如果当在RTO超时后，发送方将会把RTO设置为2*RTO,然后重启定时器。
       • 注意的是如果定时器被多次还原后，接收方会清除SRTT和RTTVAR并以测量到RTT以第一次计算方式进行运行，因为当前的SRTT和RTTVAR可能为伪造的；
     • karn算法
       • 该算法是TCP采样RTT必须使用的算法，算法指出TCP不能对重发的报文段进行RTT采样，除非设置了时间戳选项，因为时间戳选项去除离开关于数据段实例所触发的相应的不明确性，时间戳选项回对每一个ACK进行RTT采样。对RTT的每两次采样后对SRTT和RTTVAR的值进行计算时可能不能充分的考虑到历史RTT的样本。
     • 快速重传和快速恢复算法
       • 快速重传：当接收方连续发送三次同样的ACK报文段时，此时可能发生了报文段丢失，这时发送方不必等待定时器超时就可以直接发送丢失的报文段，所以这也被称为快速重传。之所以要等待3次，是因为1~2次时可能因为数据报文的乱序造成，而在此期间接收方能够有时间对乱序进行处理。
       • 快速恢复
         • 快速恢复算法是为了避免快速重传错误的使用慢启动造成吞吐量降低而出现的算法，在接收方发送3次同样的ACK报文后，发送方将ssthresh设置为cwnd的一半（四舍五入为单个报文段大小的倍数），然后将cwnd设置为ssthresh加上收到的3个ACK报文段大小的字节数。
         • 如果此期间又收到了重复的ACK报文段，则每收到一次cwnd加上一个报文段大小的字节数，并发送一份分组（如果允许发送的话）。
         • 当收到数据的ACK确认数据报后，cwnd将设置为ssthresh，此时cwnd是等于ssthresh的，这里没有让数据传输进入慢启动，而是让传输速率减半。
2. 坚持定时器
   • 坚持定时器用于在接收方通告窗口为0时，由发送方启动坚持定时器，每当坚持定时器超时，发送方会发送一次探寻报文；之所以会这样做是因为接收方的ACK报文有可能丢失，所以可能造成双方的无限等待。
   • 坚持定时器的第一次超时时间会按照RTO的时间进行定时，在此之后会按照TCP的指数退避，也就是以2指数倍进行递增，当然最终会有一个最大超时时间一般为60s，与超时重传定时器不同的是，坚持定时器会一直持续下去，直到连接的强制关闭等。
   • 糊涂窗口综合症
     • 糊涂窗口综合症的产生致使每次发送的数据报，传输开销都很大（固定的IP协议头和TCP协议头的字节消耗），但实际的有效荷载则很小。
     • 接收方
       • 问题的产生：当坚持定时器不断探查时，每当接收方接收缓存释放一点都会通告发送方，导致发送方每次发送一份非满字节的报文。
       • 解决方案：接收方通过控制通告窗口大小，当28窗口大小小于一个报文段大小或者是小于接收方窗口一半大小时（这里之所以还需要判断是否大于等于接收方，是防止接收方的接收窗口的大小小于一个报文段大小）则通告发送方当前接收方通告窗口大小为0。
     • 发送方
       • 问题的产生：在上面描述滑动窗口时，有提到过当发送数据后有可能出现数据已经读入缓存也又可能出现缓存还没有读取完成的情况，当应用程序在写入数据的速率较慢时，发送方读入缓存的数据就会出现读取数据较少的问题，这样在进行发送时，也会产生糊涂窗口综合症。
       • 解决方案
         发送报文需要满足以下任一条件：
         • 当前数据报文段必须一个满报文段
         • 当前报文段大小大于等于接收方最大窗口的一半；
         • 发送报文段之前没有等待被确认的报文或者该连接上不能使用Nagle算法。
3. 保活定时器：
   • 一般而言保活定时器都是由服务器设置（客户端也可以设置），应用程序通过Socket API设置SO_KEEPALIVE选项来开启或关闭保活定时器，而TCP内部则通过设置tcp_set_keepalive来开启或关闭定时器，保活定时器的时间一般是每两个小时进行探测（通过设置TCP的tcp_keepalive_time参数更改定时器的时间），如果中间出现数据传输则定时器复位重新进行计时，如果定时器超时发送探测发现客户端未响应，则每间隔75s（通过设置TCP的tcp_keepalive_intvl参数更改探测报文重传时间）发送一次探测，如果9次（通过设置TCP的tcp_keepalive_probes参数更改探测报文发送次数）后依然未响应则该连接关闭。
     
     • 上图展示的就是定时器超时发出的探测报文段，我们看到当定时器超时会先发送ARP报文段对客户端的地址进行解析，然后ARP协议对客户端地址进行了应答，接着服务端发送了一段误数据的分组，我们看到该报文段没有显示seq，因为在报文段为空时只能设置了SYN、FIN和RST标识位才会展示seq，这里只是填充了ack，这里填充的ack是要求客户端返回的ack数据，所以我们看到客户端返回了相同的ack；但实际按正常来说服务端发送报文段其seq就为14，返回的ack应该为15，这里的seq没打印出来但是实际值为13，这里其实是为了响应保活定时器而发送的特殊报文段。
     • 在保活定时器超时发送探测报文时一般会遇到以下四种情况：
       • 正常状态：也就是当保活定时器超时后对客户端发送探测报文，客户端进行了响应；
       • 客户端异常关闭：当客户端异常关闭时，保活定时器超时发送探测报文会出现客户端无相应的情况，这样状态下服务端就是每间隔75s发送一次探测报文，当发送9次后关闭该连接；
       • 客户端异常关闭并重启：当客户端异常关闭并重启后，保活定时器超时发送探测报文时，客户端会响应服务器一个来自服务器的复位，服务器则对连接进行复位，而客户端会打印“连接被对端复位”；
       • 客户端不可达：客户端不可达时，服务端将接收到ICMP操作报文告诉服务端目标不可达，但是服务端不会关闭该连接也是每间隔75s发送一次探测报文，当发送9次后关闭该连接，但这时会反馈给应用程序“没有找到主机的路由”。
   • 2MSL定时器：该定时器用于TCP关闭连接时，处于TIME_WAIT阶段的时使用。

TCP拓展

1. 长肥管道
   • 具有大的带宽时延乘积的网络被称为长肥网络（Long Fat Network，即LFN），管道可以被水平拉长（一个长的RTT），或被垂直拉高（较高的带宽），或向两个方向拉伸。使用长肥管道会遇到多种问题。
     • 当主机之间使用长肥管道来进行数据的传输时，在带宽较高时就需要更大的窗口来提高吞吐量，这样就可以通过窗口扩大选项来增大窗口，在TCP的选项中做了具体的描述。
     • 在一个长肥管道中数据数据时，当出现一份分组丢失的时候我们可以使用超时重传来解决，但当多个分组丢失时，即使使用算法，因为RTT的过长，导致管道最终也被耗尽。在RFC 1072中建议使用选择确认（SACK）来处理一个窗口的多个分组丢失的情况，但是在后续的RFC 1332中该选项被忽略，因为作者觉的在将其纳入TCP前需要解决一些技术问题。
     • 在一个长肥管道中RTT会难以进行测量，所以在长肥管道中需要更好的RTT测量方法，而使用时间戳选项可以使得更多的报文段可以被计时，包括重传。
     • TCP在进行报文段的传输时，都会使用到seq序号来标注当前传输非组的唯一性，而seq的字段被TCP用32bit来进行存储，当seq超出时会重新开始计算seq。已知当传输了4294967296个字节时就会出现序号回绕，回绕的seq将从0开始计算，为了防止出现序号回绕出现序号重用的问题，我们就需要使用TCP的时间戳选项的PAWS算法来保护回绕的序号。

UDP协议

1. 不可靠传输，协议头部分一共只有8个字节，其数据报长度受两个因素的影响：
   • 总长度不超过65535字节，因为一个一个IP数据报的长度不能超过65535个字节
   • 另一个是受到应用程序的限制，应用程序使用的UDP socket的读写长度将影响整个UPD数据报的长度。一般允许UDP数据报长度大于8192字节（之所以取8192是因为NFS（网络文件系统）中，8192字节是默认的读取用户数据的长度）。
2. UDP协议头结构图：
   
   • 16位源端口号：记录发送UPD数据包的主机端口号，在接收方需要回馈数据时选用。
     • 16位目标端口号：记录目标端口号，接收方通过端口号区分应用程序分发报文，如果出现对应目标端口没有找到应用程序的情况下，就丢弃该报文，并由ICMP发送“端口不可达”差错报文交给发送方。
     • 16位UDP长度：UDP报文的长度(协议头加数据)，最小为8字节(即协议头大小)。
     • 16位UPD校验和：校验UDP报文的完整性。该字段时可选的，当源主机不想计算校验和，则直接令该字段为全0；如果需要对UDP协议数据进行校验时，就如TCP使用相同的算法，并且也会生成12字节的伪头部，以此保证校验的准确。
   • UDP是不需要进行连接就能直接进行发送数据的，这样发送数据的方式因为不用保持连接所以能够支持更多的活动客户机。

会话层

1. 说明： 会话层将两台通信设备之间建立一个连接，该连接会保持到超时、设备重启、关机或是操作关闭。
2. 功能：会话层保持两台设备之前的连接通信，会话层可以实现对权限的控制，才发起会话时必须通过验证才能开启会话连接,如NFS, SQL, ASP, PHP, JSP, RSVP(资源源预留协议)等就属于会话协议

表示层

1. 表示层包括了对数据的编码格式的处理以及是否加密压缩等操作的处理

应用层

1. 应用层就是提供用户接口，特制能够发起网络通信的应用程序，由应用程序端作为触发点，开始网络信息传输。