TCP协议(3)--TCP的特点

TCP特点：
TCP通过检验和，序列号，确认应答，重发控制，连接管理以及窗口控制等机制实现可靠性传输。
通过序列号与确认应答提高可靠性：

TCP通过肯定的确认应答ACK实现可靠的数据传输。当发生端将数据发送出去之后会等待对端 的确认应答。如果有确认应答，说明数据已经成功到达对端。反之，数据丢失的可能性比较大。

在一定的时间内如果没有收到确认应答，发送端就可以认为数据已经丢失，并进行重发。由此，即使产生了丢失，仍然可以保证数据能够到达对端，实现可靠传输。

未收到确认应答并不意味着数据一定丢失，也有可能是对方已经收到，只是返回确认应答在途中丢失，也有可能是其他原因导致确认应答延迟到达，这时都会发生重传。
这时目标主机必须放弃收到重复的包。TCP使用序列号实现这功能，序列号是按照顺序给发送数据的每一个字节都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据长度，将自己下一步应该接收的序号作为应答返送回去。
这时如果发生重传，接收端收到的序号不是自己上次的应答号，则丢弃该包，并再次发送一个应答包。
连接管理：
TCP提供面向连接的通信传输。面向连接是指在数据通信开始之前先做好通信两端之间的准备工作。
建立TCP需要三次握手才能建立，而断开连接则需要四次握手。

三次握手：客户端发送SYN包给服务器，客户端进入SYN-SEND状态。服务器收到SYN包后将建立连接的SYN包和应答包一起发送给客户端，并且进入SYN-RCVD状态。客户端收到包SYN+ACK包后，发送应答包ACK给服务器。进入建立连接状态，服务器接收到应答包后进入建立连接状态。
三次握手大概就是这么个过程。
通过第一次握手，服务器知道客户端能够发送数据。通过第二次握手，客户端知道服务器能发送数据。结合第一次握手和第二次握手，客户端知道服务器能接收数据。结合第三次握手，服务器知道客户端能够接收数据。
至此，完成了握手过程，客户端知道服务器能收能发，服务器知道客户端能收能发，通信连接至此建立。三次连接是保证可靠的最小握手次数，再多次握手也不能提高通信成功的概率，反而浪费资源。此时就建立了全双工的通信。
为什么不能两次：
当客户端想要建立连接时发送一个SYN，然后等待ACK，结果这个SYN因为网络问题没有及时到达B，所以客户端在一段时间内没收到ACK后，在发送一个SYN，服务器也成功收到，然后客户端也收到ACK，这时客户端发送的第一个SYN终于到了服务器，对于服务器来说这是一个新连接请求，然后服务器又为这个连接申请资源，返回ACK，然而这个SYN是个无效的请求，客户端收到这个SYN的ACK后也并不会理会它，而服务器却不知道，服务器会一直为这个连接维持着资源，造成资源的浪费
那三次握手为什么可以？两次握手的问题在于服务器端不知道一个SYN是否是无效的，而三次握手机制因为客户端会给服务器回复第二次握手，也意味着服务器会等待客户端的第三次握手，如果第三次握手迟迟不来，服务器便会认为这个SYN是无效的，释放相关资源。但这时有个问题就是客户端完成第二次握手便认为连接已建立，而第三次握手可能在传输中丢失，服务端会认为连接是无效的，这时如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误。详细解释参考这个博客
四次挥手： 客户端发送FIN包告诉服务器，现在开始我已经没有数据可以发了，接着进入FIN-WAIT-1状态，等待应答包。服务器接收到FIN包后，发送一个应答包ACK，告诉客户端我知道了，现在我还有数据要发，先等我，接着服务器进入CLOSE-WAIT状态。客户端接收到应答包ACK后进入FIN-WAIT-2状态。之后，服务器发送完所有数据后，同样发送一个FIN包给客户端，告诉客户端，我也没有数据可以发送了，进入LAST-ACK状态，客户端接收到FIN包后发送应答包ACK给服务器，进入TIME-WAIT状态。服务器接收到应答包后进入CLOSE状态。
滑动窗口：
只考虑传输只在一个方向进行，即A发送数据，B给出确认。
发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保存，以便在超时重传时使用。
现在假定A收到了B发送过来的确认报文段，期中窗口是20字节，而确认号是31。
接着A发送了序号为31-41的数据，这时，发送窗口位置没有改变。如图

而B的接收窗口大小时20，在接收窗口外面，到30号为止的数据时已经发送过确认的，并且已经交付主机了。因此在B可以不再保留这些数据。接收窗口内的序号内的序号是允许接收的。
B收到了序号为32和33的数据，这些数据没有按序到达，因为序号为31的数据没有收到。这时B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31。
发送窗口和重发机制：
在没有使用窗口的时候，没有收到确认应答的数据都会被重发。而使用了窗口控制，某些应答即便丢失也无需重发。可以通过下一个确认应答号进行确认。

当某段报文丢失后，发送端会一直收到序号为1001的确认应答，这个确认应答好像在提醒发送端，我想接收的是从1001开始的数据。在窗口比较大的时候，又出现报文段丢失的情况下，同一个序号的确认应答将会被重复不断的返回。如果发送端连续三次收到同一个确认应答就会对数据进行重发。
TCP流量控制： 所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

设A向B发送数据，在建立连接的时候，B告诉A我的接收窗口是3000。因此，发送方发送窗口不能超过接收方给出的接收窗口的数值。
当接收方在接收了3001号开始的数据段后缓冲区即满。不得不暂时停止接收数据。之后，在接收到发送窗口更新通知后通信才得以继续进行。如果这个窗口更新的通知在发送过程中丢失了，可能导致无法通信。为解决这个事情，TCP为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就会启动一个持续计时器。若超过一定时间，就会发送一个零窗口探测报文段，而对方就在确认这个探测报文段时给出现在的窗口值。
流量控制是指点对点通信量的控制，是一个端到端的问题。（接收端控制发送端）
TCP拥塞控制： 拥塞控制就是防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。
TCP进行拥塞控制的算法有4种，即慢开始，拥塞避免，快重传和快恢复。
慢开始：当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络中，那么就有可能引起网络发送拥塞。
所以较好的办法就是由小到大逐渐增大发送窗口。在每收到一个新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS(最大报文段）的数值。
拥塞避免： 让拥塞窗口缓慢增大，即每经过一个往返时间就把发送方的拥塞窗口加1，而不是像慢开始那样加倍增长。这表明在拥塞阶段，拥塞窗口按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
快重传： 快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送的数据时才进行捎带确认，而是立即进行确认，即使收到失序的报文段也要立即发出对已收到的报文段的重复确认。