一、TCP协议
TCP全称为"传输控制协议(TransmissionControlProtocol")，也就是要对数据的传输进行一个详细的控制。
注意：由于用户通过read、recv等接口将数据从用户缓冲区拷贝到TcP的发送缓冲区后，数据什么时候发？一次发送多少？出错了怎么办？都是有TCP控制的，所以叫传输控制协议.
二、TCP协议段格式
2.1格式
（1）源/目的端口号：表示数据是从哪个进程来，到哪个进程去。
（2）32位序号/32位确认号：代表了本报文段所携带的数据的第一个字节的序号。
（3）4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节），所以TCP头部最大长度是15*4=60。（包含了选项的）
(4)6位标志位（接收方通过标志位区分TCP报文的类型）：
。URG：紧急指针是否有效。
。ACK：确认号是否有效。--确认报文的应答属性
。PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走。
。RST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段。
。SYN：请求建立连接，我们把携带SYN标识的称为同步报文段。
。FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。
（516位窗口大小：TCP报文头部里的一个字段，单位是字节，用来表示接收方当前能接收的最大数据量(也就是接收方的接收缓冲区剩余容量）。--流量控制
（6）16位校验和：发送端填充，CRC校验，接收端校验不通过，则认为数据有问题，此处的检验和不光包含TCP首部，也包含TCP数据部分。
（7)16位紧急指针：标识哪部分数据是紧急数据。
（8）40字节头部选项：位于固定20字节之后的可选扩展字段，用来在基础TCP协议之上，实现更多高级功能。
2.2两个问题：
(1)如何交付给上层？通过16位源端口号和16位目的端口号交付
(2)如何分离报头和有效载荷？先截取前20个字节，然后通过4位首部长度计算出40位字节头部选项的长度，剩下的就是有效载荷了。
TCP保证可靠性的最重要的一个机制就是确认应答机制。
注意：16位窗口大小是接收方自己剩余的缓冲区大小，目的就是进行流量控制；32位序号的作用：保证了数据的按序到达
三、序列号
TCP将每个字节的数据都进行了编号，即为序列号。
每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。
四、确认序号
当某一方向对方发送了多个数据，那么就会有很多个应答，啊呢吗如何确定哪个应答是对应
哪个的报文的，这时候就需要使用确认序号了，确认序号就是在序号的基础上加一。
确认序号的意义：表示确认序号之前的数据，已经全部收到了，下一次发送请从确认序号指定的数字（确认序号之后）开始发送。
注意：虽然TCP是保证可靠性的，但是TCP允许链接建立失败。
五、RST标志位
(1)RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。
(2)TCP处理程序会在自己认为的异常时刻发送RST包。例如，A向B发起连接，但B之上并未监听
相应的端口，这时B操作系统上的TCP处理程序会发RST包。
(3）又比如，AB正常建立连接了，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，网
断了，A通过若干原因放弃了这个连接（例如进程重启）。网通了后，B又开始发数据包，A收到后
表示压力很大，不知道这野连接哪来的，就发了个RST包强制把连接关了，B收到后会出现connect reset by peer错误。
注意：客户端在TCP的三次握手中，客户端认为自己只要把三次握手中的第三次报文发出，就认为链接建立好了。
六、URG标志位
七、确认应答机制
每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。
八、超时重传机制
情况一：数据丢包
主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B，如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了。
情况二、应答丢包
因此主机B会收到很多重复数据，那么TCP协议需要能够识别出那些包是重复的包，并且把重
复的丢弃掉，这时候我们可以利用序列号，就可以很容易做到去重的效果。
注意：TCP识别出哪些重复的包，依据的正是报文中的32位序号字段
如何确定超时的时间？
（1）最理想的情况下，找到一个最小的时间，保证"确认应答一定能在这个时间内返回"。
（2）但是这个时间的长短，随着网络环境的不同，是有差异的。
（3）如果超时时间设的太长，会影响整体的重传效率。
（4）如果超时时间设的太短，有可能会频繁发送重复的包。
TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。
（1）Linux中（BSDUnix和Windows也是如此），超时以50Oms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
（2）如果重发一次之后，仍然得不到应答，等待2*500ms后再进行重传。
（3）如果仍然得不到应答，等待4*500ms进行重传，依次类推，以指数形式递增。
（4）累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。
九、TCP的连接管理机制
在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。
服务端状态转化:
●[CLOSED->LISTEN]服务器端调用listen后进入LISTEN状态,等待客户端连接；
●[LISTEN->SYN_RCVD]一旦监听到连接请求(同步报文段),就将该连接放入内核等待队列中,并向
客户端发送SYN确认报文.
●[SYN_RCVD->ESTABLISHED]服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据了.
●[ESTABLISHED->CLOSE_WAIT]当客户端主动关闭连接(调用close),服务器会收到结束报文段，
服务器返回确认报文段并进入CLOSE_WAIT;
●[CLOSE_WAIT->LAST_ACK]进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据);当服务器真正调用close关闭连接时,会向客户端发送FIN，此时服务器进入LAST_ACK状态,等待最后一个ACK到来（这个ACK是客户端确认收到了FIN)
●[LAST_ACK->CLOSED]服务器收到了对FIN的ACK,彻底关闭连接
客户端状态转化:
●[CLOSED->SYN_SENT]客户端调用connect,发送同步报文段;
●[SYN_SENT->ESTABLISHED]connect调用成功,则进入ESTABLISHED状态,开始读写数据;
●[ESTABLISHED->FIN_WAIT_1】]客户端主动调用close时,向服务器发送结束报文段，同时进入
FIN_WAIT_1;
●[FIN_WAIT_1->FIN_WAIT_2]客户端收到服务器对结束报文段的确认,则进入FIN_WAIT_2,开始
等待服务器的结束报文段；
●[FIN_WAIT_2->TIME_WAIT]客户端收到服务器发来的结束报文段，进入TIME_WAIT,并发出
LAST_ACK;
●[TIME_WAIT->CLOSED]客户端要等待一个2MSL(Max Segment Life,报文最大生存时间)的时
间，才会进入CLOSED状态。
十、为什么要三次握手四次挥手
10.1为什么要进行三次握手？（其实三次握手可以看作四次握手）
1、可靠的验证全双工，因为对于客户端和服务端都验证了它们可以收发消息
2、一次链接可能会导致SYN洪水，两次链接会把链接的成本嫁接到服务器，三次握手是最低的握手次数，奇数次握手，可以确保一般情况，握手失败的链接成本是嫁接到客户端的，从而保证了服务器的稳定性
10.2为什么要进行四次挥手？
因为断开连接是没有数据给对方发了，发送数据可能是双发都互相发的，所以断开必须是两次。
十一、TCP状态转换
十二、TCP三次握手四次挥手的问题
12.1TCP的三次握手相关问题：
1、链接建立成功和上层的accept没有关系，三次握手是双方操作系统自已的决定。
2、listen的第二个参数加1就是全连接队列里面的队列的最大长度，在没有进行accept之前，底层会建立一个全连接队列，而listen第二个参数加1就是全连接队列的最大长度，在底层握手成功的就进入队列，不成功的就不入队列。
3、服务端并不会一直处于SYN_RECV状态，如果被建立链接的一方处于SYN_RECV状态，这种链接就叫半链接，半链接也需要维护相关的队列，这种队列不会长时间被维护。
4、一个链接进入全连接队列之前，一定要先进入半链接队列
5、listen的第二个参数为什么不能太大，也不能没有？不能没有是为了更好的利用服务器资源，防止上一个服务离开了，而这时没有了服务，不能太大是因为系统有上限，会导致服务器内存全被占用、浪费内核内存、容易被攻击
12.2TCP的四次挥手相关问题：
1、主动断开链接的一方，在四次挥手完成之后，要进入time_wait状态，等待若干时长后，自动释放。
2、主动断开的一方由于会进入tima_wait状态，也就是说该链接没有彻底被断开，ip和port也都正在被使用，那么在短时间内，这个port就是不能被使用的。
3、如果想要进行地址复用，可以马上使用这个端口，只需要调用函数setsockopt就可以了。
注意：一般只有服务器存在这个问题，客户端不存在这个问题，因为客户端使用的是由操作系统分配的随机端口
十三、TIME_WAIT状态
十四、流量控制------既保证了可靠性，也提高了效率
接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应，因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制（FlowControl)。接收端将自己可以接收的缓冲区剩余空间大小放入TCP首部中的"窗口大小"字段，通过ACK端通知发送端；
（1）窗口大小字段越大，说明网络的吞吐量越高；
（2）接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
（3）发送端接受到这个窗口之后，就会减慢自己的发送速度；
（4）如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
十五、滑动窗口
如果我们对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点，就是性能较差，尤其是数据往返的时间较长的时候。
既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）
（1）窗口大小指的是无需等待确认应答而可以继续发送数据的最大值.上图的窗口大小就是4000个字节(四个段).
（2）发送前四个段的时候，不需要等待任何ACK,直接发送；
（3）收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
（4）操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
（5）窗口越大，则网络的吞吐率就越高；
已经发送出去的数据，但是并没有收到回应的多个报文，会被保存在哪里呢？
这就和和发送缓冲区有关了，发送缓冲区会被划分为几个部分，如下：
15.1滑动窗口工作示意图：
15.2滑动窗口的丢包
十六、延迟应答
如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小
（1）假设接收端缓冲区为1M.一次收到了500K的数据;如果立刻应答，返回的窗口就是500K；
（2）但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；
（3）在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
（4）如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M；
注意：窗口越大，网络吞吐量就越大，传输效率就越高，我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
十七、捎带应答
在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是"一发一收"的，意味着客户端给服务器说了一句话，服务器不仅要会这句话还要确认应答，这个时候就可以两个合二为一，发送一个报文就可以了，这就叫捎带应答，TCP建立连接的三次握手也就是捎带应答。
十八、拥塞控制
注意：每台识别拥塞的主机都要做拥塞控制
拥塞控制是防止过多数据注入网络，避免链路/路由器过载、延迟激增、丢包频发的一套全局反
馈调节机制（核心在TCP）。虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题，因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵，在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的.TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。
（1）当TCP开始启动的时候，慢启动阈值等于窗口最大值；
（2）在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1；
（3）少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；
（4）当TCP通信开始后，网络吞吐量会逐渐上升;随着网络发生拥堵，吞吐量会立刻下降；
注意：拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。
十九、面向字节流
1、发送端：应用层数据交给TCP后，TCP视为无结构字节流，按MSS分段，可合并小字节或拆分大字节。
2、接收端：TCP按序号重组字节流，恢复原始顺序，但不还原消息边界，应用层需处理粘包/拆包。
二十、数据包黏包---相对于用户层的概念
粘包问题中的"包"，是指的应用层的数据包，在TCP的协议头中，没有如同UDP一样的"报文
长度"这样的字段，但是有一个序号这样的字段。，站在传输层的角度，TCP是一个一个报文
过来的，按照序号排好序放在缓冲区中，站在应用层的角度，看到的只是一串连续的字节数
据，那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一
个完整的应用层数据包。
20.1如何避免粘包问题呢？（明确两个包之间的边界）
(1)对于定长的包，保证每次都按固定大小读取即可，例如Request结构，是固定大小的，那
么就从缓冲区从头开始按sizeof(Request)依次读取即可。-----定长报文
（2）对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束
位置。
(3）对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序员自己来定
的，只要保证分隔符不和正文冲突即可）。
20.2解决用户层的黏包问题：
1、使用定长报文
2、使用特殊字符
3、使用自描述字段+定长报头
4、使用自描述字段+特殊字符
二十一、TCP链接异常问题
进程终止：进程终止会释放文件描述符，仍然可以发送FIN.和正常关闭没有什么区别.
机器重启：和进程终止的情况相同.
机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset.即使没有写入操作,TCP自己也内置了一个保活定时器，会定期询问对方是否还在.如果对方不在，也会把连接释放.
另外，应用层的某些协议，也有一些这样的检测机制.例如HTTP长连接中，也会定期检测对方的状态.例如QQ,在QQ断线之后,也会定期尝试重新连接.
总结:
1、进程终止：链接正常断开（正常四次挥手）。
2、机器重启：先杀掉所有进程，相当于终止进程。
3、机器掉电/网线断开：接收端会认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset，即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在，如果对方不在，也会把连接释放。
二十二、TCP的相关总结
