转载：一次完整的HTTP事务是怎样一个过程？
Posted yujiangong2
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了转载：一次完整的HTTP事务是怎样一个过程？相关的知识，希望对你有一定的参考价值。
当我们在浏览器的地址栏输入 www.linux178.com ，然后回车，回车这一瞬间到看到页面到底发生了什么呢？
以下过程仅是个人理解：
域 名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户
关于HTTP协议可以参考以下：
HTTP协议漫谈 http://kb.cnblogs.com/page/140611/
HTTP协议概览 http://www.cnblogs.com/vamei/archive/2013/05/11/3069788.html
了解HTTP Headers的方方面面 http://kb.cnblogs.com/page/55442/
以下就是上面过程的一一分析，我们就以Chrome浏览器为例：
1.域名解析
首先Chrome浏览器会解析 www.linux178.com 这个域名（准确的叫法应该是主机名）对应的IP地址。怎么解析到对应的IP地址？
① Chrome浏览器 会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存），看自身的缓存中是否有www.linux178.com 对应的条目，而且没有过期，如果有且没有过期则解析到此结束。
注：我们怎么查看Chrome自身的缓存？可以使用 chrome://net-internals/#dns 来进行查看
② 如果浏览器自身的缓存里面没有找到对应的条目，那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.
注：怎么查看操作系统自身的DNS缓存，以Windows系统为例，可以在命令行下使用 ipconfig /displaydns 来进行查看
③ 如果在Windows系统的DNS缓存也没有找到，那么尝试读取hosts文件（位于C:\\Windows\\System32\\drivers\\etc），看看这里面有没有该域名对应的IP地址，如果有则解析成功。
④ 如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器（一般是电信运营商提供的，也可以 使用像Google提供的DNS服务器）发起域名解析请求（通过的是UDP协议向DNS的53端口发起请求，这个请求是递归的请求，也就是运营商的DNS 服务器必须得提供给我们该域名的IP地址），运营商的DNS服务器首先查找自身的缓存，找到对应的条目，且没有过期，则解析成功。如果没有找到对应的条 目，则有运营商的DNS代我们的浏览器发起迭代DNS解析请求，它首先是会找根域的DNS的IP地址（这个DNS服务器都内置13台根域的DNS的IP地 址），找打根域的DNS地址，就会向其发起请求（请问www.linux178.com这个域名的IP地址是多少啊？），根域发现这是一个顶级域com域 的一个域名，于是就告诉运营商的DNS我不知道这个域名的IP地址，但是我知道com域的IP地址，你去找它去，于是运营商的DNS就得到了com域的 IP地址，又向com域的IP地址发起了请求（请问www.linux178.com这个域名的IP地址是多少?）,com域这台服务器告诉运营商的 DNS我不知道www.linux178.com这个域名的IP地址，但是我知道linux178.com这个域的DNS地址，你去找它去，于是运营商的 DNS又向linux178.com这个域名的DNS地址（这个一般就是由域名注册商提供的，像万网，新网等）发起请求（请问 www.linux178.com这个域名的IP地址是多少？），这个时候linux178.com域的DNS服务器一查，诶，果真在我这里，于是就把找 到的结果发送给运营商的DNS服务器，这个时候运营商的DNS服务器就拿到了www.linux178.com这个域名对应的IP地址，并返回给 Windows系统内核，内核又把结果返回给浏览器，终于浏览器拿到了www.linux178.com 对应的IP地址，该进行一步的动作了。
注：一般情况下是不会进行以下步骤的
如果经过以上的4个步骤，还没有解析成功，那么会进行如下步骤（以下是针对Windows操作系统）：
⑤ 操作系统就会查找NetBios name Cache（NetBIOS名称缓存，就存在客户端电脑中的），那这个缓存有什么东西呢？凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址， 就都会存在这个缓存里面。什么情况下该步能解析成功呢？就是该名称正好是几分钟前和我成功通信过，那么这一步就可以成功解析。
⑥ 如果第⑤步也没有成功，那会查询WINS 服务器（是NETBIOS名称和IP地址对应的服务器）
⑦ 如果第⑥步也没有查询成功，那么客户端就要进行广播查找
⑧ 如果第⑦步也没有成功，那么客户端就读取LMHOSTS文件（和HOSTS文件同一个目录下，写法也一样）
如果第八步还没有解析成功，那么就宣告这次解析失败，那就无法跟目标计算机进行通信。只要这八步中有一步可以解析成功，那就可以成功和目标计算机进行通信。
看下图抓包截图：
Linux 虚拟机测试，使用命令 wget www.linux178.com 来请求，发现直接使用chrome浏览器请求时，干扰请求比较多，所以就使用wget命令来请求，不过使用wget命令只能把index.html请求回 来，并不会对index.html中包含的静态资源（js、css等文件）进行请求。
抓包分析：
① 号包，这个是那台虚拟机在广播，要获取192.168.100.254（也就是网关）的MAC地址，因为局域网的通信靠的是MAC地址，它为什么需要跟网关进行通信是因为我们的DNS服务器IP是外围IP，要出去必须要依靠网关帮我们出去才行。
② 号包，这个是网关收到了虚拟机的广播之后，回应给虚拟机的回应，告诉虚拟机自己的MAC地址，于是客户端找到了路由出口。
③ 号包，这个包是wget命令向系统配置的DNS服务器提出域名解析请求（准确的说应该是wget发起了一个DNS解析的系统调用），请求的域名www.linux178.com,期望得到的是IP6的地址（AAAA代表的是IPv6地址）
④ 号包，这个DNS服务器给系统的响应，很显然目前使用IPv6的还是极少数，所以得不到AAAA记录的
⑤ 号包，这个还是请求解析IPv6地址，但是www.linux178.com.leo.com这个主机名是不存在的，所以得到结果就是no such name
⑥ 号包，这个才是请求的域名对应的IPv4地址（A记录）
⑦ 号包，DNS服务器不管是从缓存里面，还是进行迭代查询最终得到了域名的IP地址，响应给了系统，系统再给了wget命令，wget于是得到了 www.linux178.com的IP地址，这里也可以看出客户端和本地的DNS服务器是递归的查询（也就是服务器必须给客户端一个结果）这就可以开始 下一步了，进行TCP的三次握手。
2.发起TCP的3次握手
拿 到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024 < 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过 TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识 别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序（本文就以Nginx为 例），最终建立了TCP/IP的连接。
如下图：
1） Client首先发送一个连接试探，ACK=0 表示确认号无效，SYN = 1 表示这是一个连接请求或连接接受报文，同时表示这个数据报不能携带数据，seq = x 表示Client自己的初始序号（seq = 0 就代表这是第0号包），这时候Client进入syn_sent状态，表示客户端等待服务器的回复
2） Server监听到连接请求报文后，如同意建立连接，则向Client发送确认。TCP报文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到对方下一个报文段的第一个数据字节序号是x+1，同时表明x为止的所有数据都已正确收到（ack=1其实是ack=0+1,也就是期望客户 端的第1个包），seq = y 表示Server 自己的初始序号（seq=0就代表这是服务器这边发出的第0号包）。这时服务器进入syn_rcvd，表示服务器已经收到Client的连接请求，等待 client的确认。
3） Client收到确认后还需再次发送确认，同时携带要发送给Server的数据。ACK 置1 表示确认号ack= y + 1 有效（代表期望收到服务器的第1个包），Client自己的序号seq= x + 1（表示这就是我的第1个包，相对于第0个包来说的），一旦收到Client的确认之后，这个TCP连接就进入Established状态，就可以发起 http请求了。
看抓包截图：
⑨ 号包 这个就是对应上面的步骤 1）
⑩ 号包 这个对应的上面的步骤 2）
号包 这个对应的上面的步骤 3）
TCP 为什么需要3次握手？
举个例子：
假设一个老外在故宫里面迷路了，看到了小明，于是就有下面的对话：
老外： Excuse me，Can you Speak English?
小明： yes 。
老外： OK,I want ...
在问路之前，老外先问小明是否会说英语，小明回答是的，这时老外才开始问路
2个计算机通信是靠协议（目前流行的TCP/IP协议）来实现,如果2个计算机使用的协议不一样，那是不能进行通信的，所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协议，协商完成后就可以进行通信了，当然这样理解不是那么准确。
为什么HTTP协议要基于TCP来实现？
目前在Internet中所有的传输都是通过TCP/IP进行的，HTTP协议作为TCP/IP模型中应用层的协议也不例外，TCP是一个端到端的可靠的面向连接的协议，所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。
3.建立TCP连接后发起http请求
进过TCP3次握手之后，浏览器发起了http的请求（看第包），使用的http的方法 GET 方法，请求的URL是 / ,协议是HTTP/1.0
以上的报文是HTTP请求报文。
那么HTTP请求报文和响应报文会是什么格式呢？
起始行：如 GET / HTTP/1.0 （请求的方法 请求的URL 请求所使用的协议）
头部信息：User-Agent Host等成对出现的值
主体
不管是请求报文还是响应报文都会遵循以上的格式。
那么起始行中的请求方法有哪些种呢？
GET: 完整请求一个资源 （常用）
HEAD: 仅请求响应首部
POST：提交表单 （常用）
PUT: (webdav) 上传文件（但是浏览器不支持该方法）
DELETE：(webdav) 删除
OPTIONS：返回请求的资源所支持的方法的方法
TRACE: 追求一个资源请求中间所经过的代理（该方法不能由浏览器发出）
那什么是URL、URI、URN？
URI Uniform Resource Identifier 统一资源标识符
URL Uniform Resource Locator 统一资源定位符
格式如下： scheme://[username:password@]HOST:port/path/to/source
http://www.magedu.com/downloads/nginx-1.5.tar.gz
URN Uniform Resource Name 统一资源名称
URL和URN 都属于 URI
为了方便就把URL和URI暂时都通指一个东西
请求的协议有哪些种？
有以下几种：
http/0.9: stateless
http/1.0: MIME, keep-alive (保持连接), 缓存
http/1.1: 更多的请求方法，更精细的缓存控制，持久连接(persistent connection) 比较常用
一次完整的HTTP事务是怎样一个过程？(转)