面试过程中的计算机网络问题

一、HTTP中的GET与POST的区别

GET在浏览器回退是无害的，而POST会再次提交请求；

GET产生的URL地址可以被存储为书签，而POST不可以；

GET请求会被浏览器主动cache，而POST不会，除非手动设置；

GET请求只能进行url编码，而POST支持多种编码方式；

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留；

GET请求在URL中传送的参数是有长度限制的；

GET与POST更不安全，由于参数直接暴露在URL上，因此不能用于传递敏感信息；

二、TCP中的三次握手与四次挥手问题

   TCP主要报文字段意义解释：

   ACK（acknowledge）确认位：ACK=1表示确认位有效，ACK=0表示报文不含确认位讯号；

   SYN（synchronization）同步：连接请求序号标志，用于建立连接，SYN=1表示请求连接；

   seq（sequeue）：表示发送的数据字节流，确保TCP传输有序；

   ack：确认位字段的值；

   FIN（finish）结束位：结束标志，用于释放连接，FIN=1表示关闭本方数据流；

三次握手建立连接

1.1三次握手建立连接过程

建立TCP连接时：需要客户端和服务器共发送3个包；

第一次：客户端发送初始序号seq=x与SYN=1请求标志

第二次：服务器发送请求标志SYN，发送确认标志ACK，发送序列号seq=y，发送客户端的确认号ack=x+1

第三次：客户端发送ACK确认号，发送自己的序列号seq=x+1，发送对方的确认号ack=y+1

【seq在握手过程一般是连续的】

1.2 三次握手过程分析

第一次：客户端发送请求到服务器，服务端知道客户端发送，自己接受正常。SYN=1，seq=x

第二次：服务器发送确认请求给客户端，客户端知道自己发送、接收正常，服务器接收、发送正常。ACK=1，ack=x+1，SYN=1，seq=y

第三次：客户端发送确认请求已确认信息给服务器，服务器知道客户端发送、接收正常，自己接收、发送也正常。seq=

x+1，ACK=1，ack=y+1

上面分析过程可以看出，如果发生两次握手达不到让双方都得出自己与对方的发送、接收能力都正常的结论的。

四次挥手关闭连接

2.1四次挥手建立过程

第一次：客户端发出释放FIN=1，自己序列号位seq=u，进入FIN-WAIT-1状态

第二次：服务器收到客户端的释放请求后，发出ACK=1确认标志和客户端的确认号是ack=u+1，自己的序列号为seq=v，进入CLOSE-WAIT状态

第三次：客户端收到服务器确认结果后，进入FIN-WAIT-2状态。此时服务器发送释放FIN=1信号，确认标志ACK=1，确认序号ack=u+1，自己的序列号为seq=w，服务器进入LAST-ACK（最后确认态）

第四次：客户端收到回复后，发送确认ACK=1，ack=w+1，自己的序列号为seq=u+1，客户端进入TIME-WAIT（时间等待）状态。客户端经过两个最长报文段寿命后，客户端CLOSE；服务器收到确认后，立刻进入CLOSE状态。

2.2四次挥手的过程分析

第一次：客户端请求断开FIN=1，seq=u

第二次：服务器确认客户端的断开请求ACK=1，ack=u+1，seq=v

第三次：服务器请求断开FIN=1，seq=w，ACK=1，ack=u+1

第四次：客户端确认服务器的断开ACK=1，ack=w+1，seq=u+1

为什么关闭连接需要四次挥手？

四次挥手时，当收到对方的FIN断开请求时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭连接通道，需要上层应用来决定，因此，己方ACK和FIN会分开来发送

为什么客户端最后需要等待2MSL？

客户端需要保证最后一次发送的ACK报文到服务器，如果服务器未收到，可以请求客户端重新发送，这样客户端就预留出了时间再次发送，并且重启2MSL计时

如果已经建立了连接，到那时客户端突然出现故障了怎么办？

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

参考链接：

https://blog.csdn.net/u010918487/article/details/87207531

https://www.cnblogs.com/jainszhang/p/10641728.html