网路通信问题收集
网路通信问题收集
TCP/IP协议中三次握手机制
第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；
同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。
四次挥手
第一次挥手：主机1（可以是客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
窗口滑动机制的作用：
TCP协议作为一个可靠的面向流的传输协议，其可靠性和流量控制由滑动窗口协议保证，而拥塞控制则由控制窗口结合一系列的控制算法实现。
具体介绍：
窗口滑动就是说一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。
https流程：
- 浏览器将自己支持的一套加密规则发送给网站。
- 网站从中选出一组加密算法与
HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。 - 浏览器获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。 - 网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。 - 浏览器解密并计算握手消息的
HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密
TCP连接CLOSE_WAIT和TIME_WAIT状态
CLOSE_WAIT产生的原因
由上面的TCP四次挥手断开连接的过程，可以知道 CLOSE_WAIT 是主动关闭方发生FIN之后，被动方收到 FIN 就进入了 CLOSE_WAIT 状态，此时如果被动方没有调用 close() 函数来关闭TCP连接，那么被动方服务器就会一直处于 CLOSE_WAIT 状态(等待调用close函数的状态)；
所以 CLOSE_WAIT 状态很多的原因有两点：
- 代码中没有写关闭连接的代码，也就是程序有
bug; - 该连接的业务代码处理时间太长，代码还在处理，对方已经发起断开连接请求; 也就是客户端因为某种原因先于服务端发出了
FIN信号，导致服务端被动关闭，若服务端不主动关闭socket发FIN给Client，此时服务端Socket会处于CLOSE_WAIT状态（而不是LAST_ACK状态）。
TIME_WAIT产生的原因
TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭；后发FIN包的一方执行的是被动关闭。主动关闭的一方会进入 TIME_WAIT 状态，并且在此状态停留2倍的MSL（报文最大生存时间）时长。平台系统使用的是默认值60s。也就是说 TIME_WAIT 状态需要维持120秒才能释放。
在生产过程中，如果服务器使用短连接，那么完成一次请求后会主动断开连接，就会造成大量 TIME_WAIT 状态。因此我们常常在系统中会采用长连接，减少建立连接的消耗，同时也减少 TIME_WAIT 的产生，但实际上即使使用长连接配置不当时，当 TIME_WAIT 的生产速度远大于其消耗速度时，系统仍然会累计大量的 TIME_WAIT 状态的连接。 TIME_WAIT 状态连接过多就会造成一些问题。如果客户端的 TIME_WAIT 连接过多，同时它还在不断产生，将会导致客户端端口耗尽，新的端口分配不出来，出现错误，tomcat也会进入假死状态。如果服务器端的 TIME_WAIT 连接过多，可能会导致客户端的请求连接失败。
TIME_WAIT消耗内存，cpu很少，但是极端情况下会占用很多端口。相比较起来，还是CLOSE_WAIT的问题更严重！
