TCP原理

TCP的原理

确认应答，超时重传，连接管理都是TCP可靠性提供支持，TCP三次握手只对TCP可靠性提供辅助作用并不是主要作用。    

1.确认应答机制（安全机制）

保证数据安全的前提下，尽可能的提高传输效率。

客户端先传输1-1000数据，服务器确认应答返回一个ACK表示已经接收到前1000个数据下一个数据从1001开始。

 2.超时重传（安全机制）

 A主机向B主机发送了一个消息，因为网络的原因，B主机没有收到A主机发送的消息，A主机等待一段时间后没有收到B主机发送的ACK就会重新发送一遍刚才发的消息，还有一种情况是B主机收到了发送的消息，但是返回的ACK在传送的过程中丢包了，这时候B主机就会收到重复的消息，这时候有一个缓冲区专门存放所发送的数据，缓冲区会根据数据的序号，来判断是否重复接收消息了并只保留不重复的数据。

3.连接管理（安全机制）

TCP的连接不是物理上的连接而是逻辑上的连接，指的是A主机的内核中，记录了一个数据结构，里面包含了连接的对象是否（IP，端口号，网络协议）,主机B的内核中，也存在一个这样的数据结构。

1）建立连接

三次握手协议本来是四次交互中间有两次合并成了一次

 客户端TCP首先发送一个SYN（synchronize）同步报文段，然后服务器接收到消息后先发送一个ACK返回值来确认收到了报文，在发送一个SYN与客户端进行交互，然后客户端收到报文后在发送一个ACK返回值来确认收到了报文。中途SYN与ACK是可以合并到一起来发送的，因为他们两个发送的间隔非常短，服务器会把他们两个放在一起这样可以节省资源的开支。

三次握手的意义：

1.让通信双方各自建立对对方的“认同”。

2.验证通信双方各自发送能力和接收能力是否ok。

3.在握手的过程中，双方协商一些重要的参数。

LISTEN表示服务器的状态：表示服务器已经准备好了随时可以接收消息，相当于手机开机，电话随时可以接通。

ESTABLISHED客户端和服务器都有：连接建立完成，接下来就可以正常通信了。

 四次挥手断开

客户端要与服务器进行断开，客户端先向服务器发送一个，FIN服务器收到后返回一个ACK，然后服务器在发送一个FIN，客户端再返回一个ACK。这里中间的ACK和FIN不能一起发送，因为FIN的发起不是由内核进行的而是通过代码的close（）方法进行的

CLOSE_WAIT：出现在被动发起断开连接的一方，等待关闭（等待调用close方法来关闭socket）

TIME_WAIT：主动发起断开连接的一方，假设客户端断开连接，当客户端进入TIME_WAIT的状态时表示四次挥手已经挥完了。TIME_WAIT状态下TCP不会立马断开连接，当出现TIME_WAIT时表示前两次挥手已经完成，需要等待发出去ACK被服务器接收，万一发生丢包现象。

上述三次握手和四次挥手都有超时重传，

四次挥手中，如果ACK丢包了站在服务器的角度来看，不知道是自己FIN丢包了还是ACK丢包了所以就会重传FIN。

滑动窗口：

滑动窗口的本质就是降低了确认应答，等待ack消耗的时间。

 把多个等待时间放在一起发送了

丢包情况1.ack丢了：

这个没有影响因为后面发送的ack会将前面发送的ack覆盖掉，并不影响主机b确认应答。

数据丢包了

如果在2001~3000的时候syn丢包了，那么后面的ack一直就是2001表示1~2000的syn接收成功，但是后面3001~9000的数据都收到了，ack一直返回1~2000此时主机B发现不对劲就会一直向主机A索要2001~9000的ack重复几次后B仍没有收到，这时候A就要对2001~3000段的数据进行重传。这种重传的方式叫做“快速重传”

流量控制：

滑动窗口越大传输效率越高，并不是越大越好

发送窗口的大小并不是固定的值，也不是配置的，而是随着传输过程的进行，动态调整的。

当窗口大小为0的时候，发送方就要暂停发送，暂停发送这个过程，会给B定期发送一个窗口探测报文，这个报文并不带有实际的值，只是为了触发ack查询窗口大小。

拥塞控制

这个就是在危险的边缘疯狂试探。

流量控制和拥塞控制共同决定发送方的窗口大小是多少

流量控制：考虑接收方的处理能力。

拥塞控制：传输过程中中间节点的控制能力。

刚开始时候先放出少量数据进行探测，探测一下当前网络的情况，探测网络情况是否拥堵。然后开始指数性增长，到一定程度线性增长。

延时应答（也是提升效率的机制）

也是在滑动窗口的基础上操作的

主机B在收到数据后，不直接发送ACK而是等待一会，先消耗缓存中的数据，这样可以让缓存最大化利用，过一会一起发送ACK。

 

 捎带机制（效率机制）

 捎带机制跟三次握手机制不一样跟四次挥手合并更像

三次握手是一定合并，捎带机制是可能合并。

面向字节流

引入面向字节流后，引入一个麻烦是，黏包问题。

接收缓存时，多个数据放在一起有可能一次少读一段数据，有时候多读一段数据，就会发生数据的黏包问题，解决这个问题：1.设置分隔符。2.约定每个包的长度。

异常问题

在传输的过程中遇到不可抗拒性问题。

1.进程崩溃

2.主机关机

3.主机掉电

4.网线断开

1和2   3和4  属于一种情况。

1和2 情况还可以进行四次挥手但是可能没进行完，连接就断开了

3和4  是突然就断开了根本来不及挥手，假设接收方掉电了，发送方发完数据后一直收不到ack，超时重传，还收不到ack，接收方就会进行单方面断开连接，

假设是发送方掉电了，接收方发现没数据了，接收方不知道怎么办，接收方会先等待，接收方会周期性向发送方发送一个消息，确认发送方是否还在。心跳包（是一种形象比喻）心跳包来确认双方是否在处在正常通信状态下