TCP/IP协议、三次握手、四次挥手

TCP/IP协议分层

• 

TCP头部

三次握手

整个流程为：

• 客户端主动打开，发送连接请求报文段，将SYN标识位置为1，Sequence Number置为x（TCP规定SYN=1时不能携带数据，x为随机产生的一个值），然后进入SYN_SEND状态
• 服务器收到SYN报文段进行确认，将SYN标识位置为1，ACK置为1，Sequence Number置为y，Acknowledgment Number置为x+1，然后进入SYN_RECV状态，这个状态被称为半连接状态
• 客户端再进行一次确认，将ACK置为1（此时不用SYN），Sequence Number置为x+1，Acknowledgment Number置为y+1发向服务器，最后客户端与服务器都进入ESTABLISHED状态

TCP四次挥手

TCP三次握手是TCP连接建立的过程，TCP四次挥手则是TCP连接释放的过程。下面是TCP四次挥手的流程图：

• 1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
• 2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
• 3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
• 4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
• 5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
• 6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

常见问题

1、什么是TCP网络分层

分层的好处：解耦

• 各层独立：限制了依赖关系的范围，各层之间使用标准化的接口，各层不需要知道上下层是如何工作的，增加或者修改一个应用层协议不会影响传输层协议
• 灵活性更好：比如路由器不需要应用层和传输层，分层以后路由器就可以只用加载更少的几个协议层
• 能促进标准化：每一层职责清楚，方便进行标准化

2、TCP为什么是三次握手，不是两次或者四次？

• 两次握手
  • 如果TCP只进行两次连接，C端带着syn=1 seq=x询问S端是否可以连接，S端答应syn=1 seq=y ACK=1(确认) ack=x+1,C端收到答应之后就不响应了，这时S端就处于确立连接状态但是不知道C端是否处于确立连接状态，如果C端询问完收到S端消息就不处理了，S端还会一直处于确立连接状态资源不会释放导致服务端资源浪费。
• 四次握手
  • 脱裤子放屁，竟然三次握手已经能确定TCP连接可靠那么就没有必要进行四次握手，多一次握手增加连接的开销。
  • 还有一种情况，如果是四次握手那么和两次握手会出现类似的情况

3、TCP为什么是四次挥手，为什么不能是三次挥手将第二次挥手和第三次挥手合并？

在第一次挥手后S端可能还有一些数据没有发送完，如果第二次挥手要等待S端将数据都发送完成可能需要很长时间，C端处于FIN-WAIT1阶段会以为S端没有收到询问消息 会再次发送一条询问消息给S端，但是S端这个时候其实在CLOSE-WAIT中，所有必须要进行四次挥手，在S端收到询问消息之后立马回复一个ACK=1 ack=x+1（确认序列号）让C端进入一个阶段FIN-WAIT2

4、四次挥手时为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

5、如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。