标签：code 线性 协议 要求 += tcp 维护 允许 超时重传
以下都是按客户端主动连接方和主动断开连接方
【1】tcp的半关闭状态
服务器接收到客户端的FIN请求后回复了ACK确认信息，但没有发送FIN请求给客户端，就进入了半连接状态，这时客户端人可以接收服务器传来的数据但不可以发送数据；客户端可以发送数据给客户端单收不到客户端的数据：即客户端单方面断开了连接；客户端和服务器判断连接的是否断开的方法是：通过read()；的系统调用返回值为0；linux还有其他连接关闭的一些判断；
【2】tcp连接超时处理
当客户端对服务器发送请求后长时间得不到回答，客户端必然会发起重连操作（执行多次），若还得不到回应，则通知应用程序连接超时；
【3】tcp复位报文段
RST报文段；通知对方关闭连接或者重新请求连接，该报文不可被回应；
a.访问不存在的端口
b.异常终止连接：以异常方式终止连接；发送复位报文段，终止连接并丢弃发送端所有的数据；
c.处理半打开连接：当服务器或者客户端异常断开连接后；如果客户端向半打开的连接发送数据服务器则会回复复位报文；
【4】tcp交互数据流
交互数据仅包含很少的字节，使用交互数据的应用程序对数据的实时性要求很高；
【5】tcp成块数据流
成块数据的长度通常为tcp报文段允许的最大数据长度，对传输效率要求很高，例如：FTP文件传输；
对于tcp的发送缓存区和接收缓存区；tcp报文的标志位p；
【6】tcp滑动窗口
【6】tcp外带数据
紧急指针标志和紧急指针；
紧急指针的位置—tcp的报文序号的到紧急数据的位置；
【7】tcp超时重传
tcp维护一个重传定时器；如果超时未得到回答将会重新定制重传计时器；默认重传次数最少是三次，最多十五次一半对应13-30 min；
【8】tcp拥塞控制
a.拥塞控制概述：
调高网络利用率，降低丢包率，保证网络资源对每条数据的公平性；
如果网络上的延迟突然增加，那么，tcp对这个事做出的应对只有重传数据，然而重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这就导致了恶性循环，最终形成了网络风暴——tcp拥塞控制机制就是用于应对这种情况（控制发送窗口SWDN的大小以及发送SWDN的过程）
拥塞控制的最终受控变量是发送端向网络一次连续写入的数据量，我们称为SWND(发送窗口);不过，发送端最终以tcp报文段来发送数据，所以SWND限定了发送端能连续发送的tcp报文段数量(SMSS，一般等于MSS)；发送端需要合理的选择SWDN的大小，如果SWDN太大对导致网络延迟；SWDN太小会导致网络拥塞；接收方可以通过接收通告窗口（RWDN）来控制SWDN;但这显然不够，所有以发送端引入了一个称为拥塞窗口的状态量（CWDN）；实际的SWDN是min(CWDN,SWDN)；如图显示了拥塞控制的输入和输出（可见，它是一个闭环反馈控制）
b.慢启动和拥塞避免：
TCP建立好连接后，CWDN被初始化为IW（一般为2~4 SMSS）;此后发送端每收到一个ACK，CWDN += min(N,SMSS);其中N是此次确认（包含之前未被确认的)的字节；这样一来CWDN将按照指数去生长；
阈值ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入拥塞避免算法
拥塞避免算法：当拥塞窗口 cwnd 达到一个阈值时，窗口大小不再呈指数上升，而是线性上升，避免增长过快导致网络拥塞。 每当收到一个ACK，CWDN += SMSS*SMSS/CWDN，每当过了一个RTT，CWDN += min(N,SMSS)
c.快速重传和快速恢复：
以上是发送端未检测到拥塞是采用得拥塞避免算法，加下来介绍拥塞发生时的拥塞控制行为；
发送端判断拥塞产生的依据：
1）传输超时，或者TCP重传定时器溢出；
2）接收到重复的ACK确认报文段；
拥塞控制对这两种情况有两种不同的处理方法，对于第一种情况仍然使用慢启动和拥塞避免的算法；
对于第二种情况则使用快速重传和快速恢复算法（如果真的发生拥塞时）；若第二种情况发生在定时器溢出后按第一种情况处理；
当发送端检测到拥塞发生是第一种情况后启动超时重传，并且做出如下处理：
标签：code 线性 协议 要求 += tcp 维护 允许 超时重传
原文地址：https://www.cnblogs.com/xcb-1024day/p/11277967.html
