浅谈tcp 十大特性
目录
一、确认应答（ACK）机制
在TCP中，当发送端的数据达到接收主机时，接收端主机会返回一个已收到消息的通知，这个消息叫做ACK(确认应答）
TCP通过肯定的ACK实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答，如果有确认应答，说明数据已经成功到达，如果没有，那么数据有可能丢失了。
收到确认应答也并不意味着数据一定丢失，有时也有可能是因为数据收到，但是ACK却在传输的途中丢了。因此这种情况也会导致发送端因没有及时收到ACK，而认为数据没有到达目的地，从而进行重传。
二、超时重传机制
超时重传的超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍然为收到确认应答，发送端将会重发数据。不过，数据也不会无限，反复的重发。当达到一定的重发次数之后，如果仍然没有任何确认应答返回，就会判断为网络或对端主机发生异常，强制关闭连接。
三、连接管理
在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接
三次挥手：客户端向服务器建立连接，开始客户端向服务器发送一段同步报文段SYN，服务器收到之后，发送同步报文段SYN和ACK给客户端，客户端收到之后再发送一段ACK给服务器。建立连接的过程就是双方相互发送SYN，并相互发送ACK。
四次挥手的原因：四次挥手比较容易理解，就和情侣分手一样，分手是双方的事，必须要双方都同意，双方都确认。
四、滑动窗口
设想在发送端发送数据的速度很快而接收端接收速度却很慢的情况下，为了保证数据不丢失，显然需要进行流量控制， 协调好通信双方的工作节奏。 所谓滑动窗口，可以理解成接收端所能提供的缓冲区大小。 TCP利用一个滑动的窗口来告诉发送端对它所发送的数据能提供多大的缓 冲区。 由于窗口由16位bit所定义，所以接收端TCP 能最大提供65535个字节的缓冲。 由此，可以利用窗口大小和第一个数据的序列号计算出最大可接收的数据序列号。
五、流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制；
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.
六、拥塞控制
虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;
七、延时应答
在收到数据以后并不立即返回确认应答，延迟一会，等待缓冲区中数据被处理，那么剩余的缓冲区就会大些——这是延迟应答。
如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K; 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是
1M;一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
八、捎带应答
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;那么这个时候ACK就可以搭顺风车，和服务器回应的 “Fine, thank you” 一起回给客户端
九、面向字节流/粘包问题
创建一个TCP的socket，会在网络中同时创建一个发送缓冲区和接受缓冲区。刚开始会将数据写入发送缓冲区。若数据太短，则在发送缓冲区中等待，等到合适时机会将合适大小的数据以字节流的形式发送出去；若数据太长，则进行拆分，然后发送。由于TCP是全双工的，所以读写数据时没有限制，可以一次性接受所有数据；也可以每次接收一点，分多次接收。
那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界。
对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof（Request)依次读取即可。
对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);
十、异常情况/心跳包
进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
机器重启: 和进程终止的情况相同.
机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放. 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接
总结
那为什么TCP这么复杂?
因为要保证可靠性, 同时又尽可能的提高性能。