TCP三次握手及其相关问题

三次握手的过程

第一次握手：客户端发送一个SYN=1，序列号随机生成的报文给服务器（假设为j），进入SYN_SENT状态；
第二次握手：服务器收到客户端SYN=1的报文之后，知道客户端请求建立连接。发送一个SYN=1，ACK=1，acknowledge number=j+1，序列号随机生成（假设为k）的报文发送给客户端，告诉客户端自己接受到了这个请求报文并愿意与客户端建立连接；进入SYN_RCVD状态；
第三次握手：客户端检查acknowledge number是否为j+1，ACK是否为1，检查正确之后发送一个ACK=1，产生一个acknowledge number=k+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为k+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。

TCP连接可以只进行两次握手吗？为什么？

不可以。有一下两个原因：
原因一：假设客户端发出的第一个连接请求数据包没有到达服务器但他没有丢失，而是在某个网络结点长时间的滞留了。后面客户端重新发送了一个请求报文，并顺利进行了连接。但那个被滞留的数据包在连接释放以后的某个时间才到达了服务器。本来这是一个早已失效的数据包。但服务器收到此失效的数据包，就误认为是 客户端再次发出的一个新的连接请求。于是就向 客户端发出确认报文，同意建立连接。假设不采用 “三次握手”，那么只要服务发出确认，新的连接就建立了。由于现在客户端并没有发出建立连接的请求，因此不会理睬服务器的确认报文，也不会向服务器发送数据。但服务器却以为新的运输连接已经建立，并一直等待客户端发来数据。这样，服务器的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，客户端不会向服务器的确认发出确认。服务器由于收不到客户端确认，就不会与客户端建立连接。
原因二：服务器无法包证自己发送的报文能被客户端接受到。

可以采用四次握手吗？为什么？

可以。但是会降低传输的效率。
四次握手是指：第二次握手：服务器只发送ACK=1和acknowledge number=j+1的报文；而服务器的SYN=1和初始序列号在第三次握手时发送；原来协议中的第三次握手变为第四次握手。

如果三次握手中客户端发个服务器的ACK报文丢失怎么办？

由于服务器没有收到客户端的ACK报文，因此会重发之前的SYN+ACK报文（默认重发五次，之后自动关闭连接进入CLOSED状态），客户端收到后会重传ACK报文给服务器。

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

服务器每收到客户端发送的一个数据包，就会将一个计时器复位。当一定时间没有收到客户端发送的数据包（一般是2个小时），就会给客户端发送一个探测报文，之后每隔一小段时间（一般为75秒）就发送一个探测报文。连续发送10个探测报文都没有得到客户端的响应，就认为客户端出问题了，就会断开连接。

初始序列号是什么？

TCP连接的一方A，随机选择一个32位的序列号作为发送数据的初始序列号，比如为1000，以该序列号为原点，对要传送的数据进行编号：1001、1002…三次握手时，把这个初始序列号传送给另一方B，以便在传输数据时，B可以确认什么样的数据编号是合法的；同时在进行数据传输时，A还可以确认B收到的每一个字节，如果A收到了B的确认编号（acknowledge number）是3001，就说明编号为1001-3000的数据已经被B成功接受，哪怕前面编号为2001的确认数据包丢失了。