TCP特性剖析

引言：前面介绍了TCP/和UDP协议的基本特性，以及基本的字段信息，三次握手，四次挥手等。下面深入剖析TCP协议
https://blog.youkuaiyun.com/Advsance/article/details/97623764
https://blog.youkuaiyun.com/Advsance/article/details/97631156

TCP协议

TCP的保活机制：通信双方长时间没有往来，则每一段时间则给对方发送一个保活探测数据包，要求对方进行回复，多次没有回复就会断开一般为（7200s），9次。可配置
连接断开带代码的体现：
recv读完所有数据后，不再阻塞（recv默认没有数据则会阻塞），返回0
send会触发异常–程序会受到一个SIGPIPE–默认处理方式–进程退出。可以重写信号防止信号退出。
为什么是三次握手，四次挥手
三次握手：为了确认双方都有收发数据的能力，如果两次，服务端无法确定客户端能否接收发送数据。而且如果是两次的话 还有个问题如果客户端和服务端一段时间没有连接或者再次发送连接请求，那么服务端可能要为其从新再创建一个连接，防止重复
四次握手没必要，因为ACK和SYN就是一个标志位，直接一起发送就好了

四次挥手：因为被动关闭方，收到FIN请求报文后，立即进行ACK回复，揭晓来需要等待被动关闭方的用户调用close接口进行确认，缓冲区中的数据已经处理完毕/不用这些数据，才会像对方发送FIN请求报文，在得到ACK后，资源释放。

握手失败如何处理：
这里的握手失败一般指的是第三次握手，服务器等待最后一个ACK报文超时后，向客户端回复RST报文，要求重置连接报文，然后关闭释放socket。避免SYN泛洪攻击。

可靠传输

1.连接管理 ：面向连接
2.确认应答机制 每发送一次都要受到一次应答
例如一个数据的大小为1024B再，在另一端收到包后，则会发送一个ACK，并且里面会有一个1025表示数据从1025继续发，如果发送方没有收到，那么会重发（性能降低）
3.超时重传 没有收到应答就会重新传输（前三个保证数据到达对方）
4.协议字段中的序号/确认序号：包续管理
5.协议字段效验和 保证数据的正确性
TCP为了保护可靠传输，牺牲了部分性能，因此想提高性能，并且避免了一些没必要的性能损失（因ACK丢失导致的重传），提高的措施有 ： 滑动窗口机制

序号/确认序号：例如如果一个包的数据为1024B，而收到后的回复丢了，而第二个包发送过去，收到了ACK 并且等于2049那么表示第一个已经收到。
直观点的说第一条ACK丢失，但是收到了第二条数据的ACK，那么认为第一条数据已经收到。

滑动窗口机制：通信双方可以连续发送多份数据，但是对方的接收区是有限的，如果发的
很多那么就会丢的越多，而发生丢包重传，那么双方就可以先协商缓冲区的大小，通过协议字段中的窗口字段（该过程一般在三次握手的时候完成，MMS最大报文数，每条数据报中最大数据长度，不包括报头；win窗口大小，最多发送多少数数据），告诉对方一次性可以发送的最大数据量，从而减少丢包率
1）流量控制：
通过每次确认回复进行协商窗口大小，告诉对方，发送的醉倒数据大小，这个窗口大小不会超过接收缓冲区的剩余空间大小，从而避免发送太快，处理过慢，导致的接收缓冲区数据塞满，引起的丢包重传·
因为接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应. 因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端; 窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度; 如果接收端缓冲区满了, 就会将窗口置为0;
这时发送方不再发送数据, 但是需要定期发送一个窗口探测数 据段, 使接收端把窗口大小告诉发送端.
2）快速重传：当接收方接收到第二条数据，但是没有接收到第一条，则认为第一条可能丢失，则立即向发送方接发送第一条数据的重传请求，并且将这个重传请求连续发送三次，
发送方连续接收到三次重传请求，则会重传这条数据进行重传。
连续发送三次，是为了避免网络延迟，数据推迟到达，重传太快则会产生浪费。
3）拥塞控制：
发送方维护一个拥塞窗口，控制一次发送的数据量，拥塞窗口以慢启动快增长的形式控制传输的数据量，起到对网络进行探测的作用，可以避免因为网络状态不好而导致的大量丢包，如果存在丢包，那么会重新启动一个慢启动，快增长的过程。
2.捎带应答机制：接收方为每一条收到的数据组织报文，通过报文头部中的确认序号进行确认回复，这时候如果刚好要给对方发送数据，则将这次的确认回复序号直接放到要发送的这条数据头中，可以节约一条空报文的回复，提高传输效率（说白了，就是要说的话一起就说了）。减少不必要的报文传输。
**3.延迟应答机制：**接收方收到数据之后，如果立即回复，窗口大小就会降低，导致传输吞吐率降低，从而导致了传输速度降低；
而延迟的后进行回复，则缓冲区的数据可能已经被取走，那么就会相对增大窗口的大小，从而提高速度。

字节流服务
send发送的数据，会先放到socket的缓冲区中，然后操作系统选择合适的实际将数据发送出去。比如发送一个 “hello” ，操作系统不会直接发送出去，而是等一会比如此时又来了个"world"那么此时就会将两个字符串一起打包发送（等待时机到了）。 多条小数据融合成一个大包发送，可以提高一定的性能，并且接收放数据交互也比较灵活，可以一点一点的交付，也可以全部交互，从而让多个数据粘结在一起，产生粘包问题。
粘包的本质原因：tcp对传输成对数据的格式边界不敏感，不会替用户区分那条数据从那开始，从哪结束，只关注需要向用户交付多长的数据。
因此粘包问题的解决方案就是用户在用户层进行数据的边界管理：
1.特殊字符
2.数据定长
3.不定长数据但在应用头中声明数据有多长

UDP不会产生粘包因为UDP里面有数据长度，不定长数据的解决方法说白了就是参考了UDP数据长度这项。

TCP在应用层实现的协议：HTTP/FTP协议等