⼀个请求的⽣命周期（HTTP请求过程详解、TCPIP五层⽹络模型）
⼀个请求的⽣命周期
前⾔：当我们从电脑上去访问⼀个⽹址时，究竟发⽣了什么？这个问题可能是⾃⼰思考或者⾯试的时候问到，这⾥我们以访问百度⾸页为例，进⾏⼀个全⾯的HTTP请求分析。
核⼼概念
计算机⽹络核⼼结构，就是TCP/IP五层⽹络模型（OSI七层模型是将应⽤层分为了三层）
以及，每⼀层对应的协议
始于本地
键盘输⼊：你要访问www.baidu，⾃然需要在浏览器地址栏中使⽤键盘输⼊（正常情况下），这个过程就涉及到输⼊设备与计算机的交互了，这个属于物理层，这⾥就不探讨了（==其实是我不会）
请求域名：⾸先你访问的是www.baidu，并不带域名，所以浏览器会⾃动补全协议头。但是我们知道，很多时候域名会有http和https，它俩的默认端⼝⼀个是80，⼀个是443，在这⾥，⼀般都是对应域名的⽹站做了端⼝转发，http协议实现了HSTS机制来使得重定向到HTTPS下的域名。所以HTTP到HTTPS这个过程是服务器来完成的，⾄于浏览器的默认端⼝⼀直是80端⼝
路由转发
IP查：⽬前我们只知道了带协议类型的域名，那么是如何到具体的服务器的呢？我们知道，对于因特⽹内每个公有地址IP都是唯⼀的（局域⽹内不⼀定），域名相当于IP的别名，因为我们⽆法去记住⼀⼤堆⽆意义的IP地址，但如果⽤⼀堆有意义的字母组成，⼤家就能快速访问对应⽹站。
DNS解析：通过域名去查IP，先从本地缓存查，其中本地的hosts⽂件也绑定了对应IP，若在本机中⽆法查到，那么就会去请求本地区域的域名服务器（通常是你对应的⽹络运营商如移动），这个通过⽹络设置中的LDNS去查，如果还是没有命中的话，那么就去根域名服务器查，这⾥有所有因特⽹上可访问的域名和IP对应信息（根域名服务器全球共13台）。⾄少到了这⾥，我们肯定能查对应的IP了，要不就是这个域名不对。
路由转发：然后我们通过⽹卡、路由器、交换机等设备，实现两个IP地址之间的通信。这⾥⽤到的主要就是路由转发技术，根据路由表去转发报⽂。。。还有⼦⽹掩码、IP⼴播等等知识点。这⾥就不多做介绍了，计算机⽹络⾥有详细准确的概念~~
连接建⽴
三次握⼿：HTTP的底层基于TCP/IP协议，TCP连接的建⽴过程少不了三次握⼿。
第⼀次握⼿：客户端主动发送SYN包到服务器，并进⼊SYN_SEND状态，等待服务器确认
第⼆次握⼿：服务器收到SYN包并确认，发送SYN+ACK到客户端，服务器进⼊SYN_RECV状态
第三次握⼿：客户端收到SYN+ACK包，发送ACK确认连接，发送完毕后客户端和服务端进⼊ESTABLISHED状态，完成三次握⼿
数据发送：建⽴完连接后，TCP才能真正的开始传输数据==。TCP会依次、有序的发送⼀定⼤⼩的报⽂，其中包括了超时重传、拥塞窗⼝、慢开始快重传等等概念。总之加了很多机制，⽤来保证数据包的完整、有序。当然以上都只是传输层中TCP做的事，实现上在应⽤层也加了很多机制。
HTTPS：
⼤家请看这张图，⼀个完整的HTTPS由以上众多模块组成。
a. Queueing：请求等待时间
b. Stalled：从TCP建⽴连接耗时
c. DNS Lookup：DNS解析
d. Initial connection：初始化连接
e. SSL：SSL就是HTTPS的重头戏，相⽐于HTTP建⽴于TCP基础上的明⽂传输，HTTPS基于SSL/TLS，⽽SSL/TLS⼜是基于TCP/IP，也就是说SSL/TLS基于TCP基础上再做了⼀层封装，对内容进⾏加密。对HTTPS如何实现加密感兴趣的同学可以取看看相关的话题
f. TTFB：客户端发起报⽂到服务器接收到第⼀个报⽂的耗时
g. Content Download：服务器响应⽹页内容接收时间
GOOGLE原⽂解释⽂档地址需FQ
Queueing The browser queues requests when:
1There are higher priority requests.
2There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
3The browser is briefly allocating space in the disk cache
Stalled The request could be stalled for any of the reasons described in Queueing.
DNS Lookup The browser is resolving the request’s IP address.
Proxy negotiation The browser is negotiating the request with a proxy server.
Request sent The request is being sent.
ServiceWorker Preparation The browser is starting up the service worker.
Request to ServiceWorker The request is being sent to the service worker.
Waiting (TTFB) The browser is waiting for the first byte of a response. TTFB stands for Time To First Byte. This timing includes 1 round trip of latency and the time the server took to prepare the response.
Content Download The browser is receiving the response.
Receiving Push The browser is receiving data for this response via HTTP/2 Server Push.
Reading Push The browser is reading the local data previously received.
服务器处理
LVS架构：这个请求在到达某⼀个服务器前，可能还要经历重重筛选==。反作弊判断，⽹关过滤，CDN等等。其中⼤型⽹站最常见的是LVS架构。LVS分负载调度器，服务器池，共享存储。主要就是为了分布式和⾼并发场景啦。
LVS⽂档
代理服务器：接下来，这个请求总算到了服务器了。去监听它的通常是代理服务器，如Nginx、Apache等。监听到之后代理服务器会将请求转发给对应的socket去处理。⽐如Nginx和PHP的交互就是Nginx将请求转发给fastcgi_pass定义的socket（⽂件socket或IPsocket），然后通过fastcgi处理，才会真正将请求和参数丢给server，cgi-app。。。
程序处理
接下来就是代码去处理具体的逻辑，然后通过response返回啦~~
在前两篇⽂章中，我们完整的描述了计算机⽹络 OSI 五层模型的相关内容。那么，本篇将会从⼀个实践案例开始，带你从整体上重新认识我们的计算机⽹络。
我们以访问 Google 为例，当我们在浏览器地址栏中敲下回车键之后，整个计算机⽹络将会发⽣什么呢？
本机的⽹络相关参数如下：
⾸先我们应⽤层的浏览器决定向 DNS 请求解析域名「le」，那么就要遵循 DNS 协议。
DNS 运⾏在 53 号端⼝，于是浏览器会创建⼀个 UDP 套接字，标识该套接字的⼆元组分别是『⽬的 IP 地址』和『⽬的端⼝』。⽽套接字本质上就是为了唯⼀标识应⽤层进程，就是为了让响应报⽂能够到⽬的地。
那么这⾥会创建⼀个 UDP 套接字，⼆元组为「本机 IP 地址 192.168.43.138」和「随机产⽣⼀个未使⽤的端⼝号」。
接着，浏览器将 DNS 请求报⽂封装好推⼊套接字，开始我们的 DNS 解析过程。
有关 DNS 的相关细节，这⾥不再赘述了，可以参考前⾯的⽂章，拿到 DNS 服务器的响应报⽂，运输层拆开数据报，得到该报⽂的⽬的 IP 地址和⽬的端⼝号，于是对应着去
套接字交付报⽂即可。
最终我们会从『本地 DNS 服务器』得到 Google 的 IP 地址为：172.194.72.105。
整个 HTTP 请求可以说才刚刚开始：
应⽤层
浏览器封装 HTTP 请求报⽂，然后创建⼀个 TCP 套接字，采⽤四元组标识，具体为「源 IP 地址：192.168.43.138」+「源端⼝号：随机的，这⾥假设为 1234」+「⽬的 IP 地址：172.194.72.105」+「⽬的端⼝号：80」。
HTTP 报⽂也就是我们的应⽤层数据报，⼤致是这样的：
指定了⼀些请求参数与动作，以及⼀些要求响应报⽂的返回格式要求，具体的我们不细说了。
紧接着，这个报⽂会被推进 TCP 套接字中，等待运输层来收取。
运输层
运输层收取了报⽂，并判断与⽬的主机是否建⽴了 TCP 连接，这⾥假设没有。
那么，运输层将不急着发送应⽤层数据，得先判断与⽬的主机之间能够正常通讯，也就是需要『握⼿』打招呼。
『三次握⼿』的相关细节，我们这⾥也不再赘述了，上篇⽂章描述的很详细了，通过『三次握⼿』，发送端和接收端确认过发送与确认序号，分配了相应的缓存资源等。
⼀切准备就绪之后，运输层将应⽤层发过来的数据报⼜⼀层封装，添加进『源端⼝号』和『⽬的端⼝号』以及相关差错检验字段。
最后将 TCP 数据报向下传递到⽹络层。
⽹络层
⽹络层其实很简单，拿到数据报并封装成 IP 数据报，即在原 TCP 报⽂的前提之上添加『源 IP 地址』和『⽬的 IP 地址』等字段信息。
然后交由数据链路层。
链路层
数据链路层拿到 IP 数据报，它需要封装成以太⽹帧才能在⽹络中传输，也就是它需要⽬的主机的 Mac 地址，然⽽我们只知道⽬的主机的 IP 地址。
所以，链路层有⼀个 ARP 协议，直接或间接的能够根据⽬的 IP 地址获得使⽤该 IP 地址的主机 Mac 地址。
当然，ARP 协议运⾏的前提是，⽬的 IP 地址和当前发送⽅主机处于同⼀⼦⽹络中。如果不然，发送⽅将⽬的 Mac 地址填⾃⼰⽹关路由的 Mac 地址，然后通过物理层发送出去。
⽹关路由由于具有转发表和路由选择算法，所以它知道⽬的⽹络该怎么到达，所以⼀路转发，最终会发送到⽬的⽹络的⽹关路由上。
最后，⽬的⽹络的⽹关路由同样会经由 ARP 协议，取得⽬的主机的 Mac 地址，然后⼴播发送，最后被⽬的主机接受。
这样的服务器就接受到⼀个 HTTP 请求，于是它解析这个请求，确定该请求的动作是什么，也就是它需要什么东西，并构建响应报⽂，以同样的⽅式从⽹络到达源主机。
最后你将看到你想要的⾕歌搜索页⾯：
整体上我们⾃顶⽽下的描述了⼀个请求到达⽬的地的完整过程，旨在宏观上建⽴完整的框架体系，相关细节之处可以参照前两篇⽂章。
浏览器输⼊⽹址到响应的整个过程-http 请求到响应详解
这⼀过程详细来讲涉及到计算机的整个⽹络架构系统，从应⽤层到物理层都可以讲述。本讲聚焦应⽤层发⽣了什么事。
在应⽤层，浏览器⾸先需要获得将要访问的⽹站的 IP 地址，因此⾸先需要进⾏域名解析，从⽹址提取出域名，然后进⾏ DNS 请求（UDP）。⾸先在本机的域名缓存中查询，若查询不到再到直连的路由器中查询，还是没有则到直连的⽹络服务提供商的 DNS 服务器查询，查询不到则会有两种⽅式继续查询⼀种是递归⽅式，即⼀级⼀级的往上⼀级 DNS 服务器查询，直到根 DNS 服务器，此时基本能查到；
⽰例：
主机——>本地 DNS 服务器——>权限 DNS 服务器——>顶级 DNS 服务器——>根服务器。其结果是要么能查到要么报错。
⼀种是⾮递归⽅式，即直接根 DNS 服务器，然后由它指⽰要哪⼀个根服务器的下⼀级 DNS 服务器。
当查到需要的 IP 地址后，地址中没有端⼝的话则使⽤ HTTP 协议的默认短号，进⾏ TCP 的三次握⼿，与对端主机连接。
成功连接后，则可以向对端主机发送 HTTP 请求，成功收到响应则进⾏断连，即 TCP 的四次挥⼿。若
响应是重定向，则需要再⼀次发送 HTTP 请求到重定向的地址（是否需要重新 DNS 解析？）
最后浏览器解析服务器的响应内容，并显⽰再浏览器页⾯。
参考链接：
blog.csdn/lzghxjt/article/details/51458540
www.jianshu/p/aa97810e5fa4
在浏览器中输⼊www.baidu后执⾏的全部过程
在浏览器中输⼊www.baidu后执⾏的全部过程
1、客户端浏览器通过DNS解析到www.baidu的IP地址220.181.27.48，通过这个IP地址到客户端到服务器的路径。客户端浏览器发起⼀个HTTP会话到220.161.27.48，然后通过TCP进⾏封装数据包，输⼊到⽹络层。
2、在客户端的传输层，把HTTP会话请求分成报⽂段，添加源和⽬的端⼝，如服务器使⽤80端⼝监听客户端的请求，客户端由系统随机选择⼀个端⼝如5000，与服务器进⾏交换，服务器把相应的请求返回给客户端的5000端⼝。然后使⽤IP层的IP地址查⽬的端。
3、客户端的⽹络层不⽤关⼼应⽤层或者传输层的东西，主要做的是通过查路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的⼯作，我不作过多的描述，⽆⾮就是通过查路由表决定通过那个路径到达服务器。
4、客户端的链路层，包通过链路层发送到路由器，通过邻居协议查给定IP地址的MAC地址，然后发送ARP请求查⽬的地址，如果得到回应后就可以使⽤ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。
事件顺序
(1) 浏览器获取输⼊的域名www.baidu
(2) 浏览器向DNS请求解析www.baidu的IP地址
(3) 域名系统DNS解析出百度服务器的IP地址
(4) 浏览器与该服务器建⽴TCP连接(默认端⼝号80)
(5) 浏览器发出HTTP请求，请求百度⾸页
(6) 服务器通过HTTP响应把⾸页⽂件发送给浏览器
(7) TCP连接释放
(8) 浏览器将⾸页⽂件进⾏解析，并将Web页显⽰给⽤户。
涉及到的协议
socket通信在哪一层(1) 应⽤层：HTTP(WWW访问协议)，DNS(域名解析服务)
DNS解析域名为⽬的IP，通过IP到服务器路径，客户端向服务器发起HTTP会话，然后通过运输层TCP协议封装数据包，在TCP协议基础上进⾏传输
(2) 传输层：TCP(为HTTP提供可靠的数据传输)，UDP(DNS使⽤UDP传输)
HTTP会话会被分成报⽂段，添加源、⽬的端⼝；TCP协议进⾏主要⼯作
(3)⽹络层：IP(IP数据数据包传输和路由选择)，
为数据包选择路由，IP协议进⾏主要⼯作
(4)数据链路层：ICMP(提供⽹络传输过程中的差错检测)，ARP(将本机的默认⽹关IP地址映射成物理MAC地址)
相邻结点的可靠传输，ARP协议将IP地址转成MAC地址。
作为⼀个软件开发者，你⼀定会对⽹络应⽤如何⼯作有⼀个完整的层次化的认知，同样这⾥也包括这些应⽤所⽤到的技术：像浏览器，HTTP，HTML，⽹络服务器，需求处理等等。
本⽂将更深⼊的研究当你输⼊⼀个⽹址的时候，后台到底发⽣了⼀件件什么样的事～
1. ⾸先嘛，你得在浏览器⾥输⼊要⽹址:
2. 浏览器查域名的IP地址
导航的第⼀步是通过访问的域名出其IP地址。DNS查过程如下：
浏览器缓存 – 浏览器会缓存DNS记录⼀段时间。有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个⾃固定的⼀个时间（2分钟到30分钟不等）。
系统缓存 – 如果在浏览器缓存⾥没有到需要的记录，浏览器会做⼀个系统调⽤（windows⾥是gethostbyname）。这样便可获得系统缓存中的记录。
路由器缓存 – 接着，前⾯的查询请求发向路由器，它⼀般会有⾃⼰的DNS缓存。
ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这⼀般都能到相应的缓存记录。
递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进⾏递归搜索，从顶级域名服务器到Facebook的域名服务器。⼀般DNS服务器的缓存中会有域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。
DNS递归查如下图所⽰：
DNS有⼀点令⼈担忧，这就是像 或者 facebook这样的整个域名看上去只是对应⼀个单独的IP地址。还好，有⼏种⽅法可以消除这个瓶颈：是DNS查时返回多个IP时的解决⽅案。举例来说，Facebook实际上就对应了四个IP地址。
是以⼀个特定IP地址进⾏侦听并将⽹络请求转发到集服务器上的硬件设备。⼀些⼤型的站点⼀般都会使⽤这种昂贵的⾼性能负载平衡器。
地理 DNS 根据⽤户所处的地理位置，通过把域名映射到多个不同的IP地址提⾼可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话⾮常好。
是⼀个IP地址映射多个物理主机的路由技术。美中不⾜，Anycast与TCP协议适应的不是很好，所以很少应⽤在那些⽅案中。
⼤多数DNS服务器使⽤Anycast来获得⾼效低延迟的DNS查。
3. 浏览器给web服务器发送⼀个HTTP请求
因为像Facebook主页这样的动态页⾯，打开后在浏览器缓存中很快甚⾄马上就会过期，毫⽆疑问他们不能从中读取。
所以，浏览器将把⼀下请求发送到Facebook所在的服务器：
GET facebook/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 这个请求定义了要读取的URL： “facebook/”。浏览器⾃⾝定义 (User-Agent 头)，和它希望接受什么类型的相应 (Accept and Accept-Encoding头). Connection头要求服务器为了后边的请求不要关闭TCP连接。
请求中也包含浏览器存储的该域名的cookies。可能你已经知道，在不同页⾯请求当中，cookies是与跟踪⼀个⽹站状态相匹配的键值。这样cookies会存储登录⽤户名，服务器分配的密码和⼀些⽤户设置等。Cookies会以⽂本⽂档形式存储在客户机⾥，每次请求时发送给服务器。
⽤来看原始HTTP请求及其相应的⼯具很多。作者⽐较喜欢使⽤fiddler，当然也有像FireBug这样其他的⼯具。这些软件在⽹站优化时会帮上很⼤忙。
除了获取请求，还有⼀种是发送请求，它常在提交表单⽤到。发送请求通过URL传递其参数(e.g.: robozzle/puzzle.aspx?id=85)。发送请求在请求正⽂头之后发送其参数。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。