应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。
应用：Web、文件传输FTP、远程登录、电子邮件
域名：由一串用“.”分隔的名字组成的Internet上某一台计算机或计算机组的名称。www.123.com（级别自左向右由低到高，com：最高的是顶级域名）（三级域名.二级域名.顶级域名）
URL：描述一个资源在万维网上的地址。唯一标识每一个资源，不区分大小写。
<协议>://<域名 or IP地址>:<端口>/<路径>/文件名[参数=值]
http://www.microsoft.com/china/index.htm。它的含义如下：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：
1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符
2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用
3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口
4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”
5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分
7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
对比URI：
URI统一资源标识符，URI的作用像身份证号一样，URL的作用像家庭住址一样。URI就是在某一规则下能把一个资源独一无二地标识出来。
URL 还定义了如何能访问到该资源，标识一个互联网资源，并指定对其进行操作或获取该资源的方法。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。简单地说，只要能唯一标识资源的就是 URI，在 URI 的基础上给出其资源的访问方式的就是 URL。
URL是以描述位置来唯一确定的。不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。URL 是 URI 的子集。
主机与另一台主机进行远程之间的通信是通过IP地址（全球唯一标识，网络层）找到网站
DNS服务器：域名->IP地址
主机先把域名传给DNS服务器，DNS服务器把解析后的IP地址传给主机，然后主机再根据IP地址发送
例如 www . server . com（三级域名.二级域名.顶级域名）
有递归查询、迭代查询（迭代也是跟本地域名服务器迭代，最终结果由本地域名服务器返回给主机）
DNS 既使用 TCP 又使用 UDP：
当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用 TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而 TCP 允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的 TCP。
当客户端向 DNS 服务器查询域名 ( 域名解析) 的时候，一般返回的内容不会超过 UDP 报文的最大长度，即 512 字节。用 UDP 传输时，不需要经过 TCP 三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。
通过将原域名对应的 IP 地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。域名劫持往往只能在特定的网络范围内进行，范围外的 DNS 服务器能够返回正常的 IP 地址。
预防：
直接通过 IP 地址访问网站，避开 DNS 劫持。
由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让 DNS 指向正常的域名服务器以实现对目的网址的正常访问，例如将计算机首选 DNS 服务器的地址固定为 8.8.8.8。
基于C/S的协议，提供不同种类主机系统之间的文件传输能力
使用TCP实现可靠传输
服务器进程（一个进程可以给多个用户提供服务）
一个主进程和 n 个从属进程
主进程打开端口，可以连接到客户进程，然后启动从属进程，来处理单个的客户请求
从属进程里有控制进程（控制连接，传请求，全程打开）和数据传送进程（数据连接，传文件，传完就关）
要用到两个TCP连接，一个是命令链路，用来在FTP客户端与服务器之间传递命令；另一个是数据链路，用来上传或下载数据。
定义了浏览器（万维网客户进程）怎样向万维网服务器请求文档，以及服务器怎样把文档传送给浏览器（本身不算一种连接，相当于是形式的规定)
使用TCP作为支撑运输协议。一旦建立好TCP连接，就可以通过套接字接口访问TCP。（套接字：IP：端口号，应用层与传输层之间的接口）(上联应用进程，下联网络协议栈，是应用程序通过网络协议进行通信的接口)
服务器进程监听TCP的端口80，以便发现是否有客户请求服务。一旦监听到了连接建立请求，并且与客户建立好了TCP连接后（TCP连接是传输层），浏览器就可以开始发出浏览界面的请求，发送http请求报文，请求相关的文档。服务器收到请求报文后，把资源以文档的形式放到http响应报文中，返回给客户。之后就可以释放TCP连接
1、浏览器分析URL，本地host文件有的话就直接解析了
2、浏览器向DNS请求解析IP地址
3、DNS解析出IP地址
4、浏览器与服务器建立TCP连接（传输层，三次握手建立连接）（第三次握手可以发送http请求报文，作为第三次握手的数据发送给服务器）。（！先建立TCP连接后才能发HTTP请求）
客户端向服务器发送http请求报文。
5、浏览器发出取文件命令（http请求报文）
6、服务器响应（http响应报文）
7、释放TCP连接
8、浏览器显示
http协议是无状态的：同一个客户第二次访问的时候响应是相同的（协议本身）（就不知道是哪个客户）
http协议采用TCP作为运输层协议，但http协议本身是无连接的（通信双方在交换http报文之前不需要先建立http连接，但是得建立TCP连接）（其实就是一个请求和响应）
http连接方式：持久连接（非流水线式、流水线式）、非持久连接
非持久：之前的连接会断掉，再次请求得重新建立TCP连接
持久：再次请求就不需要再建立TCP连接，在之前建立的连接的基础上继续请求服务器发送响应后的一段时间内仍保持连接
Web应用程序是使用HTTP协议传输数据的。HTTP 是无连接无状态的，无法从连接上跟踪会话。
会话跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。
常用的会话跟踪技术是Cookie与Session，都是用来记录信息确定用户身份的。
Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
Cookie由服务器生成，发送给浏览器，下一次请求同一网站时会把该Cookie发送给服务器。
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。响应报文里Set-Cookie的首部字段信息通知客户端保存Cookie。下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie 值后发送出去。服务器端发现客户端发送过来的Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
优点：服务器不用保存状态信息， 减轻服务器存储压力，同时便于服务端做水平拓展。
缺点：该方式不够安全，因为状态信息存储在客户端，这意味着不能在会话中保存机密数据。除此之外，浏览器每次发起 HTTP 请求时都需要发送额外的 Cookie 到服务器端，会占用更多带宽。
步骤：
优点：安全性高，因为状态信息保存在服务器端。
缺点：由于大型网站往往采用的是分布式服务器，浏览器发送的 HTTP 请求一般要先通过负载均衡器才能到达具体的后台服务器，倘若同一个浏览器两次 HTTP 请求分别落在不同的服务器上时，基于 Session 的方法就不能实现会话保持了。
【解决方法：采用中间件，例如 Redis，我们通过将 Session 的信息存储在 Redis 中，使得每个服务器都可以访问到之前的状态信息】
都是用来跟踪浏览器用户身份的会话方式
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户。
简单的说，当你登陆一个网站的时候，如果web服务器端使用的是session，那么所有的数据都保存在服务器上，客户端每次请求服务器的时候会发送当前会话session id，服务器根据当前session id判断相应的用户数据标志，以确定用户是否登陆或具有某种权限。
由于数据是存储在服务器上面，所以你不能伪造。SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效。
cookie和session的区别：
cookie数据保存在客户端，session数据保存在服务端
当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)
记住密码功能就是使用永久cookie写在客户端电脑，下次登录时，自动将cookie信息附加发送给服务端。
token的意思是“令牌”，是用户身份的验证方式。是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。
Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
session与token的区别：
每行末尾是回车符和换行符来表示换行。（换行符：\n，回车符：\r）
头部的最后有单独的一行回车符和换行符来跟数据间隔开。
请求行
首部行
实体主体（通常不用）
GET /index.html HTTP/1.1
Host：www.test.edu.cn
Connection：Close
Cookie：123
| 方法 | |
|---|---|
| GET | 请求从服务器获取资源。请求指定的页面信息，并返回具体内容，通常只用于读取数据。请求获取资源。 |
| POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。 |
| HEAD | 与 GET 相同，但只返回 HTTP 报头，不返回文档主体 |
| PUT | 替换指定的资源，没有的话就新增。 |
| DELETE | 删除指定资源 |
| OPTIONS | 向服务器发送该方法，会返回对指定资源所支持的 HTTP 请求方法。 |
| CONNECT | 要求用隧道协议连接代理。 |
| TRACE | 追踪路径。 |
| PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新。 |
| GET | POST | |
|---|---|---|
| 目的 | 请求从服务器获取资源。 | 提交数据请求处理。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。 |
| 数据位置 | 在 URL 中发送的，有长度限制，只支持 URL 编码（真正限制 GET 长度的是浏览器） | 在 HTTP 消息主体中发送的，对数据长度没有要求，支持多种编码格式。 |
| 安全性 | 可被缓存、保留在浏览器历史记录中、可被收藏为书签 -》不应在处理敏感数据时使用 | 不会被缓存、不会保留在浏览器历史记录中、不能被收藏为书签 |
| 后退按钮/刷新 | 无害 | 数据会被重新提交 |
| 1XX | 提示信息，表示目前是协议处理的中间状态。 | 100 继续：已经收到请求的一部分，正在等待其余部分。 |
| 2XX | 成功，报文已经被收到并被正确处理。 | 200 OK：成功。204 No Content：成功，但是响应报文没有实体主体。206 Partial Content：用于分块下载或断点续传，表示只是其中一部分。 |
| 3XX | 重定向，资源位置发生变动。 | 301 Moved Permanently：永久重定向，请求的URL已经不在了，要用新的重新访问。302 Found：临时重定向。 |
| 4XX | 客户端错误，请求报文有误，服务器无法处理。 | 400 Bad Request：请求报文有误（笼统的）。403 Forbidden：服务器禁止访问该资源。404 Not Found：请求的资源在服务器上不存在或未找到。 |
| 5XX | 服务器错误。 | 500 Internal Server Error：笼统错误码。501 Not Implemented：请求的功能还不支持。502 Bad Gateway：服务器作为网关或者代理时返回的错误码，访问后端服务器发生了问题。503 Service Unavailable：服务器当前很忙，暂时无法相应。 |
短连接：每次发起一个HTTP请求，都要重新建立一个TCP连接，传完一次后就关闭。而且是串行请求，增加通信开销。
必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户机和服务器都要分配 TCP 的缓冲区和变量，这给服务器带来的严重的负担，因为一台 Web 服务器可能同时服务于数以百计的客户机请求。创建和关闭连接的过程也消耗资源和时间。
为了减少资源消耗，缩短响应时间，就需要重用连接。
HTTP/1.1 版本中默认使用持久连接，在此之前的 HTTP 版本的默认连接都是使用非持久连接。想要长连接的话要在报文首部行加上connection ：keep-alive，会有一个保持时间。
在 Keep-Alive 方式下，服务器在响应后保持该 TCP 连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户机时，可以在单个持久 TCP 连接上进行。
当长时间的保持 TCP 连接时容易导致系统资源被无效占用，若对 Keep-Alive 模式配置不当，将有可能比非 Keep-Alive 模式带来的损失更大。因此，我们需要正确地设置 keep-alive timeout 参数，当 TCP 连接在传送完最后一个 HTTP 响应，该连接会保持 keepalive_timeout 秒，之后就开始关闭这个链接。
长连接情况下，多个HTTP请求可以复用同一个TCP连接，这就节省了很多TCP连接建立和断开的消耗。
长连接：多用于操作频繁，点对点的通讯，而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。
短连接：用户数目较多的Web网站的 HTTP 服务一般用短连接。例如京东，淘宝这样的大型网站一般客户端数量达到千万级甚至上亿，若采用长连接势必会使得服务端大量的资源被无效占用，所以一般使用的是短连接。
长连接使得可以流水线处理（管道传输）：可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
HTTP/1.1 相比 HTTP/1.0：
HTTP/2 相比 HTTP/1.1：
……
HTTP协议以明文方式发送内容，不提供任何方式的数据加密，不验证通信方的身份，无法证明报文的完整性。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。
HTTPS = HTTP + 加密 + 认证 + 完整性保护
为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。HTTPS是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。
SSL（Secure Socket Layer），在http的基础上添加了一个安全传输层，对所有的数据都加密后再进行传输，客户端和服务器端收到加密数据后按照之前约定好的秘钥解密。（HTTP 先和 SSL 通信，再由 SSL 和 TCP通信）
SSL 需要四次握手。
加密：
对称加密（加密和解密用的是同一个密钥）、非对称加密（加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的）、哈希算法（将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆）、数字签名（签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过）
对称加密：双方拥有相同的密钥，信息得到安全传输，但此种方式的缺点是：
（1）不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高
（2）因每个客户端、服务器的安全级别不同，密钥极易泄露
非对称加密：客户端用公钥对请求内容加密，服务器使用私钥对内容解密，反之亦然，但上述过程也存在缺点：
公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容。（理解成客户端是用公钥来加密和解密，服务器端是用私钥来加密和解密）（使用公钥进行加密的信息，只有和其配对的私钥可以解开。）
而且非对称加密的速度很慢，效率低。
在正式的使用场景中一般都是对称加密和非对称加密结合使用，使用非对称加密完成秘钥的传递，然后使用对称秘钥进行数据加密和解密。
即用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据
服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全着得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。
但是也有安全性问题：服务器以明文的方式给客户端传输公钥的时候，中间人截取了这把属于服务器的公钥，并且把中间人自己的公钥冒充服务器的公钥传输给了客户端。之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥传输给服务器，这个时候中间人又把密钥给截取了，中间人用自己的私钥对这把被加密的密钥进行解密，解密后中间人就可以获得这把密钥了。最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。该安全性问题的原因在于客户端不知道这个公钥是否属于服务器。
所以就用数字证书来证明。服务器在给客户端传输公钥的过程中，会把公钥以及服务器的信息通过Hash算法生成信息摘要。为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。并且，最后还会把原来没Hash算法之前的个人信息以及公钥和数字签名合并在一起，形成数字证书。
（假设中间人篡改了证书原文，由于他没有 CA 机构的私钥，所以无法得到此时加密后的签名，因此无法篡改签名。）
当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。（Hash不可逆）
（数字签名是服务器把信息摘要用CA提供的私钥加密，客户端用CA提供的公钥解密）
服务器一开始就向认证中心申请了这些证书，而客户端也会事先内置这些证书。
当客户端收到服务器传输过来的数据数字证书时，就会在内置的证书列表里，查看是否有解开该数字证书的公钥，如果有则…，如果没有则…
之后是用服务器发来的公钥加密之后要的对称密钥，然后发给服务器，服务器用私钥解密。之后就用对称密钥
（黑客主要是要在客户端和服务器端之间进行拦截，拦截到的如果有部分不能解或者解完改了不能还原的话，就是失败的，主要是没有私钥）
也就是：
总SSL连接建立的过程：
① 客户端发起一个 HTTPS 请求，并连接到服务器的 443 端口，发送的信息主要包括自身所支持的算法列表和密钥长度等；
② 服务端将自身所支持的所有加密算法与客户端的算法列表进行对比并选择一种支持的加密算法，然后将它和其它密钥组件一同发送给客户端。
③ 服务器向客户端发送一个包含数字证书的报文，该数字证书中包含证书的颁发机构、过期时间、服务端的公钥等信息。
④ 最后服务端发送一个完成报文通知客户端 SSL 的第一阶段已经协商完成。
⑤ SSL 第一次协商完成后，客户端发送一个回应报文，报文中包含一个客户端生成的随机密码串，称为 pre_master_secre，并且该报文是经过证书中的公钥加密过的。
⑥ 紧接着客户端会发送一个报文提示服务端在此之后的报文是采用pre_master_secre 加密的。
⑦ 客户端向服务端发送一个 finish 报文，这次握手中包含第一次握手至今所有报文的整体校验值，最终协商是否完成取决于服务端能否成功解密。
⑧ 服务端同样发送与第 ⑥ 步中相同作用的报文，已让客户端进行确认，最后发送 finish 报文告诉客户端自己能够正确解密报文。
当服务端和客户端的 finish 报文交换完成之后，SSL 连接就算建立完成了，之后就进行和 HTTP 相同的通信过程，唯一不同的是在 HTTP 通信过程中并不是采用明文传输，而是采用对称加密的方式，其中对称密钥已经在 SSL 的建立过程中协商好了。
=》HTTPS传输更安全：
（1） 所有信息都是加密传播，黑客无法窃听。
（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。
（3） 配备身份证书，防止身份被冒充。
相比 HTTP 协议，HTTPS 协议增加了很多握手、加密解密等流程，虽然过程很复杂，但其可以保证数据传输的安全。
相同网络环境下，HTTPS 协议会使页面的加载时间延长近 50%，增加 10%到 20%的耗电。此外，HTTPS 协议还会影响缓存，增加数据开销和功耗。
HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用
对比：
假如我们需要抓取客户端的数据包，需要监控客户端与服务器交互之间的网络节点，监控其中任意一个网络节点（网卡），获取所有经过网卡中的数据，对这些数据按照网络协议进行解析，这就是抓包的基本原理。而中间的网络节点不受我们控制，是基本无法实现抓包的，因此只能在客户端与服务器之间进行抓包。
当采用抓包工具抓取 HTTP 数据包时，过程较为简单：
这里抓包工具相当于透明人，数据经过的时候它一只手接到数据，然后另一只手把数据传出去。
抓包工具对客户端来说相当于服务器，对服务器来说相当于客户端。在这个传输过程中，客户端会以为它就是目标服务器，服务器也会以为它就是请求发起的客户端。
① DNS 解析：当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个 IP 地址，因此我们需要先把域名转换成相应 IP 地址。
② TCP 连接：浏览器通过 DNS 获取到 Web 服务器真正的 IP 地址后，便向 Web 服务器发起 TCP 连接请求，通过 TCP 三次握手建立好连接后，浏览器便可以将 HTTP 请求数据发送给服务器了。（有了TCP连接才能发HTTP请求，所以得先建立TCP连接！）
③ 发送 HTTP 请求：浏览器向 Web 服务器发起一个 HTTP 请求，HTTP 协议是建立在 TCP 协议之上的应用层协议，其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。在这一过程中，会涉及到负载均衡等操作。
④ 处理请求并返回：服务器获取到客户端的 HTTP 请求后，会根据 HTTP 请求中的内容来决定如何获取相应的文件，并将文件发送给浏览器。
⑤ 浏览器渲染：浏览器根据响应开始显示页面，首先解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。
⑥ 断开连接：客户端和服务器通过四次挥手终止 TCP 连接。【其中的细节放在传输层详细讲解】