您的位置:首页 > 其它

从输入url到页面展示到底经历了什么

2017-06-11 00:23 387 查看
这是一个非常经典的问题。结合网上的众多资料,我现在对这个问题进行一下总结。

1、在浏览器输入url地址

2、DNS域名解析

     浏览器会首先查看本地硬盘的 hosts 文件,如果有和这个域名对应的IP地址,就直接使用 hosts 文件里面的 ip 地址。

     没有的话,浏览器会发出一个 DNS请求到本地DNS服务器,解析得到对应的IP地址。

3、浏览器向 web 服务器发送一个 HTTP 请求

建立TCP连接,发送http请求。

(1)TCP三次握手



第一次握手:客户端A将标志位SYN置为1,随机产生一个值为seq=J(J的取值范围为=1234567)的数据包到服务器,客户端A进入SYN_SENT状态,等待服务端B确认;

第二次握手:服务端B收到数据包后由标志位SYN=1知道客户端A请求建立连接,服务端B将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给客户端A以确认连接请求,服务端B进入SYN_RCVD状态。

第三次握手:客户端A收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给服务端B,服务端B检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,客户端A和服务端B进入ESTABLISHED状态,完成三次握手,随后客户端A与服务端B之间可以开始传输数据了。

(2)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为什么要3次握手,不是两次?

既然总结了TCP的三次握手,那为什么非要三次呢?怎么觉得两次就可以完成了。那TCP为什么非要进行三次连接呢?在谢希仁的《计算机网络》中是这样说的:

为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

在书中同时举了一个例子,如下:

“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”

这就很明白了,防止了服务器端的一直等待而浪费资源。

4、服务器处理http请求

5、服务器返回http响应

6、浏览器解析页面内容

部分内容转自:

http://www.jianshu.com/p/23b388f8e5aa

http://www.jellythink.com/archives/705

http://www.cnblogs.com/xianyulaodi/p/6547807.html

http://www.cnblogs.com/Jessy/p/3535612.html


内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: