TCP协议保证可靠交付的部分特点总结

一、使用UGG和PSH状态字段重点内容
1、URG推送位
紧急数据的起始点=序号；
紧急数据的终止点=序号+紧急指针；

（综上，紧急指针就是记录紧急数据的字节数，紧急指针永远为正数）

1）在紧急数据后面的数据为普通数据，需要按序缓存
2）窗口为0也可以发送紧急数据
3）紧急数据都处理完成后，tcp就告诉进程恢复到正常操作
  例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消程序的运行。因此用户从键盘发出中断命令（Ctrl+C）。如果不使用紧急数据，那么这两个字符会被存储在接受TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才会被交付给接收方。这样就浪费了很多时间。

URG强调的是直接读取数据,我们不会将该数据复制到缓存中,我个人认为,这个数据(紧急指针指向的数据)并不是真正意义上的"数据",而是对真正意义上"数据"的一种操作.

2、PSH推送位
PSH=1，该报文希望，到达对端时，将这个报文及缓存区之间缓存尚未交付的数据一并交付给进程。
1)PSH的数据=本报文数据+缓存区数据
2)PSH的方向—>单方向（接收PSH报文的一端）

PSH强调的是尽快将数据交付给上层(协议),而不需要经过强迫数据交互(默认tcp/ip是将数据缓存到一定的上限,再将数据递交给上层,以提高网络性能).可见,该部分数据是需要复制到缓存中的

3、区别
URG交付给进程的数据：只有紧急数据

PSH交付给进程的数据：缓冲区排好序的数据及当前报文中的数据
两者的共同点：都是一种对数据的处理方式.只不过URG是处理在前端(收到数据后立马对真正意义上"数据"进行操作,所以说"紧急.而PSH是在处理的后端,告诉内核,不用等待"满了"再递交数据递交到上层.

二、使用TCP定时器重点内容

重传计时器：Retransmission Timer
坚持计时器：Persistent Timer
保活计时器：Keeplive Timer
时间等待计时器：Time_Wait Timer。

（1）重传计时器：

重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。当TCP发送报文段时，就创建这个特定报文段的重传计时器，可能发生两种情况：若在计时器超时之前收到对报文段的确认，则撤销计时器；若在收到对特定报文段的确认之前计时器超时，则重传该报文，并把计时器复位；

重传时间=2*RTT；

RTT的值应该动态计算。常用的公式是：RTT=previous RTT*i + （1-i）*current RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上当前RTT值的10%.

Karn算法：对重传报文，在计算新的RTT时，不考虑重传报文的RTT。因为无法推理出：发送端所收到的确认是对上一次报文段的确认还是对重传报文段的确认。干脆不计入。

（2）坚持计时器：persistent timer

 专门为对付零窗口通知而设立的。

 当发送端收到零窗口的确认时，就启动坚持计时器，当坚持计时器截止期到时，发送端TCP就发送一个特殊的报文段，叫探测报文段，这个报文段只有一个字节的数据。探测报文段有序号，但序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP，确认已丢失，必须重传。

 坚持计时器的截止期设置为重传时间的值，但若没有收到从接收端来的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送探测报文段，将坚持计时器的值加倍和复位，知道这个值增大到阈值为止（通常为60秒）。之后，发送端每隔60s就发送一个报文段，直到窗口重新打开为止；

（3）保活计时器：keeplive timer

每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段（没75秒发送一个）还没收到响应，则终止连接。

（4）时间等待计时器：Time_Wait Timer

 在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。

三、采用三次握手，四次挥手重点内容

 *三次握手：*采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
 *四次挥手：*TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
 *主动断开连接的一方进入TIME_WAIT状态：*客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间(后有MSL的解释)，进入CLOSED状态。

 TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。
因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态 。
TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。