一、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