1：在浏览器地址键入URL，按下回车之后经历的流程
首先浏览器会依据URL逐层查询DNS服务器缓存，解析URL中的域名所对应的IP地址。DNS地址从近到远依次是浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存，从哪个缓存找到对应的IP则直接返回，不再查询后面的缓存。
找到IP地址后，根据IP地址和对应端口(默认80端口)和服务器建立TCP连接。
浏览器发出读取文件的HTTP请求，该请求发送给服务器。
服务器对浏览器请求作出响应，并把对应的带有HTML文本的HTTP响应报文发送给浏览器。
浏览器解析HTML渲染页面
浏览器释放TCP连接
2：为什么TCP客户端最后还要发送一次确认呢？
主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
3：如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
4：当在传送完数据之后，客户端会和服务端之间有四次握手
第一次握手：客户端发送一个FIN和序号过去（seq=u），用来表示客户端和服务端之间有关闭的请求，同时关闭客户端到服务端的数据传送，客户端就进入FIN_WAIT_1的状态。
第二次握手：服务端收到FIN=1的标志位时，就会发送一个ACK标志位代表确认，然后确认序号就变成了收到的序号加1，即ack=u+1（FIN和SYN在这点上相同，但是作用不一样）这时候服务端进入CLOSE_WAIT状态，这是一个半关闭状态。只能服务端给客户端发送数据而客户端不能给服务端发送数据。
第三次握手：这次握手还是由服务端发起，这是服务端在传完最后的数据（没有就不传）就会发送一个FIN=1和ACK=1，且序号seq会改变（没有传数据则不变），而ack不变。这时候服务端就会进入LAST_ACK状态，表示最后确认一次。
第四次握手：客户端在接收到FIN之后，就会进入TIME_WAIT状态，接着就发送一个ACK和seq=u+1,ack=w+1给服务端，这时候服务端就会进入CLOSED状态。而客户端进入TIME_WAIT状态的时候必须要等待2MSL的时间才会关闭
网友评论