从输入url到页面返回到底发生了什么

更多腾讯海量技术文章，请关注云加社区：https://cloud.tencent.com/developer/column

作者：云+社区用户

1. 前言

本文适合具有一定的计算机网络相关背景知识的读者，不过只要最低不要比笔者还低就行。笔者在这方面大概战五渣的水平。

2. 网络通信过程

1. 域名解析

互联网上穿梭的数据包基本都是IP包，所以笔者与博客园新闻站点服务器传输的也是IP包，那么我们就需要博客园新闻站点服务器的IP地址。对于浏览器的使用者来说，我们只需要告诉浏览器我们需要的地址（在地址栏键入域名），那么之后解析IP地址的任务就会由浏览器代劳了。

IP包的格式为IP+TCP+HTTP。

检查本地的host文件，如果有对应的IP地址，依然选择直接返回给浏览器；否则，进入第3步。

检查本地的DNS服务器设置并发给消息给它，由它帮忙查找，这时解析IP地址的任务就由DNS进程交给了远程的DNS服务器。

DNS进程将查询返回的IP地址 114.55.49.182 存入自身缓存并返回给浏览器。

2. HTTP打包

TCP进程和IP进程在本文中是一个抽象概念，专指操作系统内核对TCP/IP协议族的实现。

HTTP 是一个客户端和服务器端请求和响应的标准TCP。

3. 三次握手

TCP进程作风稳健，所以并不会轻易地将HTTP包和IP地址发给IP进程，所以这就引出了TCP通信三次握手。三次握手中，TCP进程决定先不发HTTP包，而是先要确保自己的IP包能够被远程服务器正常接收，同时，远程服务器的IP包也能被己方机器正常接收。

TCP进程：洞腰洞腰，我是洞拐，听到请回话 Cnblogs服务器：洞拐洞拐，我是洞腰，我听到了 TCP进程：OK，我听到你说话了。

4. HTTP数据传输

所谓兵马未动，粮草先行，还没真正进行数据交流呢，双方就已经传递了三个IP包了。不过这样一来，双方都能听到对方的回复了。现在TCP进程可以委托IP进程安心大胆地发送包含HTTP数据的IP包了。

这里还有一个问题，由于发送的IP包都是通过分组交换发出的，所以TCP进程怎么知道哪个IP包被服务端正确地接收了呢。这里就引出了SEQ和ACK的概念。

SEQ=Sequence Number ACK=Acknowledge Number

这两个字段分别被包裹在TCP头部（别忘了我们的IP包组成结构）。比如我们每次要传输1000字节的数据，初始序列号为1，那么就将SEQ设置为1，然后本地的TCP进程就把这1000个字节打包，然后层层地封装、传输，并最终到达服务器TCP进程。

5. 服务器传回网页

cnblogs新闻站点服务器将首页封装成HTTP格式，通过TCP进程按照类似第4步的流程返回给我们的机器。这一个过程，数据传输也是基于分组交换的方式。所以又是两个IP包（只考虑一次传输）。

6. 释放TCP连接

经过两边不断的“交易”，网页数据终于基本传输完毕了，我们的浏览器也根据报文内容渲染出了最终的界面。但是这就结束了吗？显然还没有，我们还需要释放TCP连接以回收资源。

计算机上建立了大量TCP连接却没有释放可是要出大问题的，《使用HttpClient的优解》

不同于通信连接阶段的三次握手，释放TCP连接则是四次握手。类比通信的一端有一个数据传输口和一个数据接收口，分别是另一端的数据接收口和数据传输口，这两根管道需要依次被关闭。

TCP进程：洞腰洞腰，我是洞拐，数据传输完毕，我要关闭连接我的数据传输口了 Cnblogs服务器：洞拐洞拐，我是洞腰，我听到了，你关闭吧 （TCP进程默默关闭数据传输口（Cnblogs服务器的数据接收口）） Cnblogs服务器：洞拐洞拐，我是洞腰，数据传输完毕，我要关闭连接我的数据传输口了 TCP进程：洞腰洞腰，我是洞拐，我听到了，你关闭吧 （Cnblogs服务器默默关闭数据传输口（TCP进程的数据接收口））

不考虑超时重传，这里又用了4个IP包。

让我们用一张图作为本次数据传输的总结。其中SYN（synchronous）是TCP/IP建立连接时使用的握手信号。

从图上也可以很直观的看出，本次通信总共用了3+2*2（双向通信）+4=11个IP包。