网络协议知识总结HTTP协议 HTTP协议的优点和缺点 HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的

HTTP协议

HTTP协议的优点和缺点

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。

HTTP协议具有以下优点：

支持客户端/服务器模式
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
无连接：无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
无状态：HTTP 协议是无状态协议，这里的状态是指通信过程的上下文信息。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能会导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就比较快。
灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

HTTP协议具有以下缺点：

无状态： HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。
明文传输： 协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。
不安全

（1）通信使用明文（不加密），内容可能会被窃听；（2）不验证通信方的身份，因此有可能遭遇伪装；（3）无法证明报文的完整性，所以有可能已遭篡改；

GET 请求和 POST 请求的区别

github.com/sisterAn/bl…

github.com/febobo/web-…

GET方法请求一个指定资源的表示形式，使用GET的请求应该只被用于获取数据

POST方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用

本质上都是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中会体现出一些区别

从w3schools得到的标准答案的区别如下：

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark（网页书签），而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET参数通过URL传递，POST放在Request body中

PUT和POST的区别

PUT 和 POST 的区别：PUT 主要用于更新或创建资源，而 POST 主要用于在服务器上创建新资源。幂等性是指对同一资源的多次请求是否会产生相同的效果。PUT 的幂等性体现在多次执行相同的请求，资源的状态不会发生变化。POST 不是幂等的，因为多次执行相同的请求可能会创建多个相同的资源。

语义：

PUT：用于更新或创建资源。当客户端使用 PUT 请求向服务器发送数据时，它期望这些数据将替代目标资源的内容。如果资源存在，它将被完全替代；如果资源不存在，PUT 请求可能会创建一个新的资源。
POST：用于向服务器提交数据，通常用于在服务器上创建新的资源。POST 请求不是幂等的，即相同的请求可能会产生不同的结果。

使用场景：

PUT：适用于更新资源，客户端提供完整的数据以替代目标资源的内容。例如，修改文章内容或更新用户信息。
POST：适用于在服务器上创建新资源，通常用于提交表单数据，上传文件等。例如，创建新的博客文章或上传用户文件。

常见的HTTP请求头和响应头

HTTP Request Header 常见的请求头：

Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级
Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。
Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。
Authorization 是用来告知服务器，用户代理的认证信息
User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器
Host 会告知服务器，请求的资源所处的互联网主机名和端口号。 Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段
Range 即可告知服务器资源的指定范围
If-Modified-Since 会告知服务器若If-Modified-Since 字段值早于资源的更新时间，则希望能处理该请求。用于确认代理或客户端拥有的本地资源的有效性。

HTTP Responses Header 常见的响应头：

Content-Type：text/html;charset=UTF-8 告诉客户端，资源文件的类型，还有字符编码，
Accept-Ranges :是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。
ETag 能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的 ETag 值。
Content-Length 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据
Expires：应该在什么时候认为文档已经过期
Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT 所请求的对象的最后修改日期
Content-Encoding:gzip 告诉客户端，服务端发送的资源是采用gzip编码的，客户端看到这个信息后，应该采用gzip对资源进行解码。
Set-Cookie：设置和页面关联的Cookie。
Refresh: 5; url=baidu.com 用于重定向，或者当一个新的资源被创建时。默认会在5秒后刷新重定向。
Date: Tue, 03 Apr 2018 03:52:28 GMT 这个是服务端发送资源时的服务器时间，GMT是格林尼治所在地的标准时间。

HTTP常见请求方法简介

HTTP请求的常用方法有：1、GET方法；2、POST方法；3、HEAD方法；4、PUT方法；5、DELETE方法；6、CONNECT方法；7、OPTIONS方法；8、TRACE方法：9、 PATCH方法；这9种。

1、GET方法

GET方法用于根据指定的 URI（统一资源标识符）从给定服务器中检索信息，即从指定资源中请求数据。使用GET方法的请求应该只是检索数据，并且不应对数据产生其他影响。注意 GET请求的不安全性，在地址栏和历史记录中明文显示。

2、HEAD方法

HEAD方法与GET方法基本相同，只不过返回的响应中没有具体的内容，用于获取报头。这对于查看响应头的数据非常有用，无需传输整个内容。HEAD方法常被用于客户端查看服务器的性能。

3、POST方法

POST方法用于将数据发送到服务器以创建或更新资源，它要求服务器确认并处理请求中包含的数据内容，这个请求可能会建立新的资源或/和修改现有资源。

POST请求永远不会被缓存，且对数据长度没有限制；我们无法从浏览器历史记录中查找到POST请求。

4、PUT方法

PUT方法用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容。

它会将包含的元素放在指定的 URI 下，如果 URI 指示的是当前资源，则会被更新取代；如果指定 URI 没有资源，会新增并将元素添加进去。

5、DELETE方法

DELETE方法用来删除指定 URI 的资源，它会删除 URI 给出的目标资源的所有当前内容。

6、CONNECT方法

CONNECT方法开启一个客户端到请求资源之间的双向沟通的隧道；它是HTTP/1.1协议预留的，可以将链接改成管道方式的代理服务器。

7、OPTIONS方法

OPTIONS请求与HEAD相似，通常也是用于客户端查看服务器的性能。这个方法会请求服务器返回该资源所支持的预定义URL的HTTP策略。该方法会用 ’*’ 来代替资源名称，向服务器发送OPTIONS请求，能够测试服务器功能是否正常。JavaScript的 XMLHttpRequest 对象进行CORS跨域资源共享时，就是使用OPTIONS方法发送嗅探请求，以判断是否有对指定资源的访问权限。

8、TRACE方法

TRACE回显服务器收到的请求，该方法主要用于HTTP请求的测试或诊断。

9、PATCH方法

PATCH请求与PUT请求相似，一样用于资源的更新。两者有区别，PATCH通常用于资源的部分更新，而PUT通常用于资源的总体更新。 PATCH 与 PUT 属性上的一个重要区别还在于：PUT 是幂等的，而 PATCH 不是幂等的。

幂等性是指对同一资源的多次请求是否会产生相同的效果。

PUT把一个包含了修改某项数据后的完整资源对象传给后端，做完整更新。这种方法浪费带宽，效率低下。于是PATCH诞生，只传一个修改字段到指定资源去，表示该请求是一个局部更新，后端仅更新接收到的字段。

6. OPTIONS请求方法及使用场景

OPTIONS是除了GET和POST之外的其中一种 HTTP请求方法。

OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。该请求方法的响应不能缓存。

OPTIONS请求方法的主要用途有两个：

获取服务器支持的所有HTTP请求方法；
用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

常见的HTTP状态码

状态码的类别：

类别	原因	描述
1xx	Informational(信息性状态码)	接受的请求正在处理
2xx	Success(成功状态码)	请求正常处理完毕
3xx	Redirection(重定向状态码)	需要进行附加操作一完成请求
4xx	Client Error (客户端错误状态码)	服务器无法处理请求
5xx	Server Error(服务器错误状态码)	服务器处理请求出错

302 重定向，304缓存。

1. 2XX (Success 成功状态码)

状态码2XX表示请求被正常处理了。

（1）200 OK

200 OK表示客户端发来的请求被服务器端正常处理了。

（2）204 No Content

该状态码表示客户端发送的请求已经在服务器端正常处理了，但是没有返回的内容，响应报文中不包含实体的主体部分。一般在只需要从客户端往服务器端发送信息，而服务器端不需要往客户端发送内容时使用。

（3）206 Partial Content

该状态码表示客户端进行了范围请求，而服务器端执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

2. 3XX (Redirection 重定向状态码)

3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

（1）301 Moved Permanently

永久重定向。 该状态码表示请求的资源已经被分配了新的 URI，以后应使用资源指定的 URI。新的 URI 会在 HTTP 响应头中的 Location 首部字段指定。若用户已经把原来的URI保存为书签，此时会按照 Location 中新的URI重新保存该书签。同时，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

使用场景：

当我们想换个域名，旧的域名不再使用时，用户访问旧域名时用301就重定向到新的域名。其实也是告诉搜索引擎收录的域名需要对新的域名进行收录。
在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。

（2）302 Found

临时重定向。 该状态码表示请求的资源被分配到了新的 URI，希望用户（本次）能使用新的 URI 访问资源。和 301 Moved Permanently 状态码相似，但是 302 代表的资源不是被永久重定向，只是临时性质的。也就是说已移动的资源对应的 URI 将来还有可能发生改变。若用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。同时，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。

使用场景：

当我们在做活动时，登录到首页自动重定向，进入活动页面。
未登陆的用户访问用户中心重定向到登录页面。
访问404页面重新定向到首页。

（3）303 See Other

该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。 303 状态码和 302 Found 状态码有着相似的功能，但是 303 状态码明确表示客户端应当采用 GET 方法获取资源。

303 状态码通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。

注意：

当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成GET，并删除请求报文内的主体，之后请求会再次自动发送。
301、302 标准是禁止将 POST 方法变成 GET方法的，但实际大家都会这么做。

（4）304 Not Modified

浏览器缓存相关。 该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

带条件的请求（Http 条件请求）：使用 Get方法请求，请求报文中包含（if-match、if-none-match、if-modified-since、if-unmodified-since、if-range）中任意首部。

状态码304并不是一种错误，而是告诉客户端有缓存，直接使用缓存中的数据。返回页面的只有头部信息，是没有内容部分的，这样在一定程度上提高了网页的性能。

（5）307 Temporary Redirect

307表示临时重定向。 该状态码与 302 Found 有着相同含义，尽管 302 标准禁止 POST 变成 GET，但是实际使用时还是这样做了。

307 会遵守浏览器标准，不会从 POST 变成 GET。但是对于处理请求的行为时，不同浏览器还是会出现不同的情况。规范要求浏览器继续向 Location 的地址 POST 内容。规范要求浏览器继续向 Location 的地址 POST 内容。

3. 4XX (Client Error 客户端错误状态码)

4XX 的响应结果表明客户端是发生错误的原因所在。

（1）400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

（2）401 Unauthorized

该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。若之前已进行过一次请求，则表示用户认证失败

返回含有 401 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。

以下情况会出现401：

401.1 - 登录失败。
401.2 - 服务器配置导致登录失败。
401.3 - 由于 ACL 对资源的限制而未获得授权。
401.4 - 筛选器授权失败。
401.5 - ISAPI/CGI 应用程序授权失败。
401.7 - 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

（3）403 Forbidden

该状态码表明请求资源的访问被服务器拒绝了，服务器端没有必要给出详细理由，但是可以在响应报文实体的主体中进行说明。进入该状态后，不能再继续进行验证。该访问是永久禁止的，并且与应用逻辑密切相关。

IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因：

403.1 - 执行访问被禁止。
403.2 - 读访问被禁止。
403.3 - 写访问被禁止。
403.4 - 要求 SSL。
403.5 - 要求 SSL 128。
403.6 - IP 地址被拒绝。
403.7 - 要求客户端证书。
403.8 - 站点访问被拒绝。
403.9 - 用户数过多。
403.10 - 配置无效。
403.11 - 密码更改。
403.12 - 拒绝访问映射表。
403.13 - 客户端证书被吊销。
403.14 - 拒绝目录列表。
403.15 - 超出客户端访问许可。
403.16 - 客户端证书不受信任或无效。
403.17 - 客户端证书已过期或尚未生效
403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

（4）404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。以下情况会出现404：

404.0 -（无） – 没有找到文件或目录。
404.1 - 无法在所请求的端口上访问 Web 站点。
404.2 - Web 服务扩展锁定策略阻止本请求。
404.3 - MIME 映射策略阻止本请求。

（5）405 Method Not Allowed

该状态码表示客户端请求的方法虽然能被服务器识别，但是服务器禁止使用该方法。GET 和 HEAD 方法，服务器应该总是允许客户端进行访问。客户端可以通过 OPTIONS 方法（预检）来查看服务器允许的访问方法, 如下

javascript
复制代码Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE

4. 5XX (Server Error 服务器错误状态码)

5XX 的响应结果表明服务器本身发生错误.

（1）500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。

（2）502 Bad Gateway

该状态码表明扮演网关或代理角色的服务器，从上游服务器中接收到的响应是无效的。注意，502 错误通常不是客户端能够修复的，而是需要由途经的 Web 服务器或者代理服务器对其进行修复。以下情况会出现502：

502.1 - CGI （通用网关接口）应用程序超时。
502.2 - CGI （通用网关接口）应用程序出错。

（3）503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。

使用场景：

服务器停机维护时，主动用503响应请求；
nginx 设置限速，超过限速，会返回503。

（4）504 Gateway Timeout

该状态码表示网关或者代理的服务器无法在规定的时间内获得想要的响应。他是HTTP 1.1中新加入的。

使用场景：代码执行时间超时，或者发生了死循环。

5. 总结

（1）2XX 成功

200 OK，表示从客户端发来的请求在服务器端被正确处理
204 No content，表示请求成功，但响应报文不含实体的主体部分
205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
206 Partial Content，进行范围请求

（2）3XX 重定向

301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
302 found，临时性重定向，表示资源临时被分配了新的 URL
303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

（3）4XX 客户端错误

400 bad request，请求报文存在语法错误
401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
403 forbidden，表示对请求资源的访问被服务器拒绝
404 not found，表示在服务器上没有找到请求的资源

（4）5XX 服务器错误

500 internal sever error，表示服务器端在执行请求时发生了错误
501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

6. 同样是重定向，307，303，302的区别？

302是http1.0的协议状态码，在http1.1版本的时候为了细化302状态码⼜出来了两个303和307。 303明确表示客户端应当采⽤get⽅法获取资源，他会把POST请求变为GET请求进⾏重定向。 307会遵照浏览器标准，不会从

post变为get。

HTTP状态码304是多好还是少好

服务器为了提高网站访问速度，对之前访问的部分页面指定缓存机制，当客户端在此对这些页面进行请求，服务器会根据缓存内容判断页面与之前是否相同，若相同便直接返回304，此时客户端调用缓存内容，不必进行二次下载。

状态码304不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。

搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于304的状态，那么蜘蛛可能会降低对网站的抓取次数。相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么日积月累，的回访率也会提高。

产生较多304状态码的原因：

页面更新周期长或不更新
纯静态页面或强制生成静态html

304状态码出现过多会造成以下问题：

网站快照停止；
收录减少；
权重下降。

如何查看当前HTTP版本

两种查看http版本的方法，第一种是看请求头的内容

对于2.0的请求头，会包含authority、method、path、scheme等信息，而1.0直接会写GET /HTTP / 1.1

第二种方式，控制台输入：window.chrome.loadTimes()，根据内部的npnNegotiatedProtocol属性来查看http版本。

http各版本间的区别

HTTP0.9 是第一个版本的HTTP协议，已经过时。它的组成极其简单，只允许客户端发送GET这一种请求，且不支持请求头。HTTP0.9具有典型的无状态性，每个事务独立进行处理，事务结束时就释放这个连接。

HTTP1.0

HTTP1.0是HTTP协议的第二个版本，它的特点如下：

任何格式的内容都可以发送，这使得互联网不仅可以传输文字，还能传输图像、视频、二进制。
除了GET命令，增加了POST、HEAD等命令，丰富了浏览器与服务器的互动手段；
HTTP请求和回应格式也变了，除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据；
增加状态码（status code）、多字符集支持、多部分发送（multi-parttype)、权限（authorization)、缓存（cache）、内容编码（content encoding）等

HTTP/1.0 版的主要缺点是，每个 TCP 连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。TCP 连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0 版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

HTTP1.1

[特点]

默认使用Connection: keep-alive 长连接（persistent connection），即 TCP 连接默认不关闭，避免了连接建立和释放的开销。
引入了管道机制（pipeline），即在同一个 TCP 连接里面，客户端可以同时发送多个请求（响应的顺序必须和请求的顺序一致）
客户端请求的头信息新增了 Host 字段，用来指定服务器的域名
请求头引入range字段，支持断点续传。
新增了一些浏览器缓存相关的字段（If-None-Match、Cache-Control等）
采用分块传输编码，对于一些很耗时的动态操作，服务器需要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用"流模式"（stream）取代"缓存模式"（buffer）；
1.1 版还新增了许多动词方法：PUT、 OPTIONS、DELETE。

[不足]

虽然 1.1 版允许复用 TCP 连接，但是同一个 TCP 连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为"队头堵塞" （Head-of-line blocking）。为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入 CSS 代码、域名分片（domain sharding）等等。

HTTP2.0

HTTP2.0 的特点是：在不改动 HTTP 语义、方法、状态码、URI 及首部字段的情况下，大幅度提高了 web 性能。

二进制传输：在应用层（HTTP2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层。在二进制分帧层上，HTTP2.0 会将所有传输的信息分为更小的消息和帧，并采用二进制格式编码，其中 HTTP1.x 的首部信息会被封装到 Headers 帧，而 Request Body 则封装到 Data 帧；
多路复用：废弃了HTTP/1.1中的管道，同一个TCP连接里，客户端和服务器可以同时发送多个请求和多个响应，并且不用按照顺序来。（数据帧乱序发送后可以在另一端通过每个桢首部的流标识符来重新组装），解决了队头阻塞问题。
头部信息压缩：在 HTTP1.0 中，我们使用文本的形式传输 header，在 header 中携带 cookie 的话，每次都需要重复传输几百到几千的字节，这着实是一笔不小的开销。在 HTTP2.0 中，我们使用了 HPACK（HTTP2 头部压缩算法）压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。
服务器推送：服务端可以在客户端某个请求后，主动推送其他资源；

HTTP3.0

limeii.github.io/2019/06/htt…

HTTP2.0基于tcp协议实现，存在主要问题如下：

队头阻塞：HTTP/2 多个请求是跑在一个 TCP 连接中的，那么当 TCP 丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。
TCP 与 TLS 的握手时延迟：发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手（TLS 1.2）的过程，另外，TCP 由于具有「拥塞控制」的特性，所以刚建立连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接产生“减速”效果。
网络迁移需要重新连接：一个 TCP 连接是由四元组（源 IP 地址，源端口，目标 IP 地址，目标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手，这不利于移动设备切换网络的场景，比如 4G 网络环境切换成 WiFi。

这些问题都本质都是 TCP 协议机制本身决定的，所以无论应用层的 HTTP/2 在怎么设计都无法逃脱。因此HTTP3.0就是用来从根本解决这些问题

Google实现了一个基于UDP协议的QUIC协议，并用在了HTTP3上面。

QUIC 协议的优点有很多，这里举例几个，比如：

无队头阻塞；
更快的连接建立；
连接迁移；
向前纠错机制

无队头阻塞：QUIC 协议可以在同一条连接上并发传输多个 Stream，Stream 可以认为就是一条 HTTP 请求。由于 QUIC 使用的传输协议是 UDP，UDP 不关心数据包的顺序，如果数据包丢失，UDP 也不关心。QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。

更快的连接建立：基于UDP协议，不需要三次链接握手，并且QUIC 内部包含 TLS 1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

连接迁移：QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本；

向前纠错：每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

什么是长连接？Keep-alive

Keep-Alive的建立过程：

客户端向服务器在发送请求报文同时在首部添加发送Connection字段
服务器收到请求并处理 Connection字段
服务器回送Connection:Keep-Alive字段给客户端
客户端接收到Connection字段
Keep-Alive连接建立成功

HTTP keep-alive 也称为 HTTP 长连接。它通过重用一个 TCP 连接来发送/接收多个 HTTP请求，来减少创建/关闭多个 TCP 连接的开销

keep-alive 是客户端和服务端的一个约定，如果开启 keep-alive，则服务端在返回 response 后不关闭 TCP 连接；同样的，在接收完响应报文后，客户端也不关闭连接，发送下一个 HTTP 请求时会重用该连接。

在 HTTP/1.0 协议中，如果请求头中包含：Connection: keep-alive

如果客户端在接收完所有的信息之后还没有关闭连接，则服务端相应的资源还在被占用（尽管已经没用了）。例如 Tomcat 的 BIO 实现中，未关闭的连接会占用对应的处理线程，如果一个长连接实际上已经处理完毕，但关闭的超时时间未到，则该线程会一直被占用（使用 NIO 的实现没有该问题）。web 服务软件一般都会提供 keepalive_timeout 参数，用来指定 HTTP 长连接的超时时间。

比如设置了 HTTP 长连接的超时时间是 60 秒，web 服务软件就会启动一个定时器，如果客户端在完后一个 HTTP 请求后，在 60 秒内都没有再发起新的请求，定时器的时间一到，就会触发回调函数来释放该连接。

显然，如果客户端和服务端的确需要进行多次通信，则开启 keep-alive 是更好的选择，例如在微服务架构中，通常微服务的使用方和提供方会长期有交流，此时最好开启 keep-alive。

14. HTTP2的头部压缩算法是怎样的？

HTTP2的头部压缩是HPACK算法。在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，采用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。

具体来说:

在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新；
每个新的首部键值对要么被追加到当前表的末尾，要么替换表中之前的值。

例如下图中的两个请求，请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销。

HTTP请求报文的是什么样的？

请求报⽂有4部分组成:

请求⾏
请求头部
空⾏
请求体

其中： （1）请求⾏包括：请求⽅法字段、URL字段、HTTP协议版本字段。它们⽤空格分隔。例如，GET /index.html HTTP/1.1。（2）请求头部:请求头部由关键字/值对组成，每⾏⼀对，关键字和值⽤英⽂冒号“:”分隔

User-Agent：产⽣请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：请求的主机名，允许多个域名同处⼀个IP地址，即虚拟主机。

（3）请求体: post put等请求携带的数据

HTTP响应报文的是什么样的？

请求报⽂有4部分组成:

响应⾏
响应头
空⾏
响应体

响应⾏：由网络协议版本，状态码和状态码的原因短语组成，例如 HTTP/1.1 200 OK 。
响应头：响应部⾸组成
响应体：服务器响应的数据

pipeline和长连接的区别？和多路复用的区别

pipeline是建立在长连接的基础上得以实现的，

对于长连接-非pipeline，发一条，收一条，发一条，收一条，没收到就不能发送下一条信息

而对于pipeline,可以发1 发2 发3 然后收1 收2 收3，但是要确保发的顺序一致，并且一个收卡住，后面全都卡住。

而多路复用基于http二进制分帧机制，废弃了HTTP/1.1中的管道，同一个TCP连接里，客户端和服务器可以同时发送多个请求和多个响应，并且不用按照顺序来。（数据帧乱序发送后可以在另一端通过每个桢首部的流标识符来重新组装），解决了队头阻塞问题。

HTTPS页面能发送HTTP请求吗

developer.mozilla.org/zh-TW/docs/…

不可以，https页面不能发http请求。会触发混合内容警告，当用户访问使用HTTPS的页面时，他们与web服务器之间的连接是使用SSL加密的，是安全的，从而保护连接不会受到攻击。如果HTTPS页面包括由普通明文HTTP连接加密的内容，那么连接只是被部分加密：非加密的内容可以被入侵，并且可以被中间人攻击者修改，因此连接不再受到保护。

混合内容又分为主动混合内容和被动混合内容。

被动混合内容是指不与页面其余部分进行交互的内容，包括图像、视频和音频内容 ，以及无法与页面其余部分进行交互的其他资源。
主动混合内容指的是能与页面交互的内容，包括浏览器可下载和执行的脚本、样式表、iframe、flash 资源及其他代码。

如果非要在https中发起http请求，可以借助被动混合内容的加载，使用加载图片的方式发起请求，

const img = new Image();
img.src = 'http的请求地址'

也可以增加一层反向代理，将前端https请求代理到后端http服务

HTTP长连接与TCP长连接区别

HTTP keep-alive 也称为 HTTP 长连接。它通过重用一个 TCP 连接来发送/接收多个 HTTP请求，来减少创建/关闭多个 TCP 连接的开销

keep-alive 是客户端和服务端的一个约定，如果开启 keep-alive，则服务端在返回 response 后不关闭 TCP 连接；同样的，在接收完响应报文后，客户端也不关闭连接，发送下一个 HTTP 请求时会重用该连接。web 服务软件一般都会提供 keepalive_timeout 参数，用来指定 HTTP 长连接的超时时间。

而对于TCP的长连接其实就是 TCP 的保活机制

如果两端的 TCP 连接一直没有数据交互，达到了触发 TCP 保活机制的条件，那么内核里的 TCP 协议栈就会发送探测报文。

如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
如果对端主机崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。

所以，TCP 保活机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活，这个工作是在内核完成的。

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用程序」实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「内核」实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接。

URI与URL和URN的区别和联系

URI = Uniform Resource Identifier 统一资源标志符

URL = Uniform Resource Locator 统一资源定位符

URN = Uniform Resource Name 统一资源名称

URI：

定义：用于标识某一特定资源的唯一标识符，就是在某一规则下能把一个资源独一无二地标识出来。
包含：URI包括两个子集，即URL和URN。

URL（用地址定位）：

定义：URL是URI的一种具体类型，提供了一种用地址定位资源的方式。
结构：协议（如http、https）、主机名、端口、路径等组成部分
例子： www.example.com/page.html 是一个URL。

URN（用名称定位）：

定义： URN是URI的另一个子集，用于通过一个独特的名字标识资源。
例子： urn:isbn:0451450523 是一个URN，用于标识特定的ISBN号。

网络模型

OSI七层模型

ISO为了更好的使网络应用更为普及，推出了OSI参考模型。

（1）应用层

OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。

在客户端与服务器中经常会有数据的请求，这个时候就是会用到http(hyper text transfer protocol)(超文本传输协议) 或者https.在后端设计数据接口时，我们常常使用到这个协议。
FTP是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如百度网盘``迅雷应该是基于此协议的。
SMTP是simple mail transfer protocol（简单邮件传输协议） 。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。

（2）表示层

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

在项目开发中，为了方便数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。

（3）会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

（4）传输层

传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。

（5）网络层

本层通过 IP 寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。

（6）数据链路层

将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。

（7）物理层

实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

OSI七层模型通信特点：对等通信 对等通信，为了使数据分组从源传送到目的地，源端OSI模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信。在每一层通信过程中，使用本层自己协议进行通信。

TCP/IP五层协议

TCP/IP五层协议和OSI的七层协议对应关系如下：

应用层 (application layer) ：直接为应用进程提供服务。应用层协议定义的是应用进程间通讯和交互的规则，不同的应用有着不同的应用层协议，如 HTTP协议（万维网服务）、FTP协议（文件传输）、SMTP协议（电子邮件）、DNS（域名查询）等。
传输层 (transport layer) ：有时也译为运输层，它负责为两台主机中的进程提供通信服务。该层主要有以下两种协议：

- 传输控制协议 (Transmission Control Protocol，TCP)：提供面向连接的、可靠的数据传输服务，数据传输的基本单位是报文段（segment）；
- 用户数据报协议 (User Datagram Protocol，UDP)：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性，数据传输的基本单位是用户数据报。

网络层 (internet layer) ：有时也译为网际层，它负责为两台主机提供通信服务，并通过选择合适的路由将数据传递到目标主机。
数据链路层 (data link layer) ：负责将网络层交下来的 IP 数据报封装成帧，并在链路的两个相邻节点间传送帧，每一帧都包含数据和必要的控制信息（如同步信息、地址信息、差错控制等）。
物理层 (physical Layer) ：确保数据可以在各种物理媒介上进行传输，为数据的传输提供可靠的环境。

从上图中可以看出，TCP/IP模型比OSI模型更加简洁，它把应用层/表示层/会话层全部整合为了应用层。

在每一层都工作着不同的设备，比如我们常用的交换机就工作在数据链路层的，一般的路由器是工作在网络层的。在每一层实现的协议也各不同，即每一层的服务也不同，下图列出了每层主要的传输协议：

同样，TCP/IP五层协议的通信方式也是对等通信：

如何理解CDN？说说实现原理？

CDN是什么

CDN(全称 Content Delivery Network)是一种分布式服务器系统，通过在全球各地部署服务器，并在这些服务器上缓存站点的静态内容，以提高用户访问站点时的速度和性能。通过 CDN，网站的内容可以更快地传送给用户，从而改善用户体验、降低延迟和提高网站的稳定性。简而言之，CDN 就是一种通过在全球范围内分布服务器来缓存网站内容并将其提供给用户的技术。简单来讲，CDN 就是根据用户位置分配最近的资源。

CDN的工作原理

在没有应用CDN时，我们使用域名访问某一个站点时的路径为

用户提交域名→浏览器对域名进行解释→DNS 解析得到目的主机的IP地址→根据IP地址访问发出请求→得到请求数据并回复

应用CDN后，DNS 返回的不再是 IP 地址，而是一个CNAME(Canonical Name ) 别名记录，指向CDN的全局负载均衡

负载均衡系统

由于没有返回IP地址，于是本地DNS会向负载均衡系统再发送请求，则进入到CDN的全局负载均衡系统进行智能调度：

看用户的 IP 地址，查表得知地理位置，找最近的边缘节点
看用户所在的运营商网络，找相同网络的边缘节点
检查边缘节点的负载情况，找负载较轻的节点
其他，比如节点的“健康状况”、服务能力、带宽、响应时间等

结合上面的因素，得到最合适的边缘节点，然后把这个节点返回给用户，用户就能够就近访问 CDN 的缓存代理。

整体流程如下图：

缓存代理

缓存系统是 CDN的另一个关键组成部分，它通过在CDN边缘节点上缓存和管理网站的静态内容，提供了更快速、高效的内容传输给用户，从而改善了用户体验、降低了延迟，并减轻了源服务器的负载压力。

其中有两个衡量CDN服务质量的指标：

命中率：用户访问的资源恰好在缓存系统里，可以直接返回给用户，命中次数与所有访问次数之比
回源率：缓存里没有，必须用代理的方式回源站取，回源次数与所有访问次数之比

缓存系统也可以划分出层次，分成一级缓存节点和二级缓存节点。一级缓存配置高一些，直连源站，二级缓存配置低一些，直连用户。回源的时候二级缓存没有只找一级缓存，一级缓存没有才回源站，可以有效地减少真正的回源。

CDN 目的是为了改善互联网的服务质量，通俗一点说其实就是提高访问速度。 它构建了全国、全球级别的专网，让用户就近访问专网里的边缘节点，降低了传输延迟，实现了网站加速。通过CDN的负载均衡系统，智能选择边缘节点提供服务，相当于CDN服务的大脑，而缓存系统相当于CDN的心脏，缓存命中直接返回给用户，否则回源。

TCP与UDP

什么是UDP

UDP（User Datagram Protocol），用户数据包协议，是一个简单的面向数据报的通信协议，即对应用层交下来的报文，不合并，不拆分，只是在其上面加上首部后就交给了下面的网络层

也就是说无论应用层交给UDP多长的报文，它统统发送，一次发送一个报文

而对接收方，接到后直接去除首部，交给上面的应用层就完成任务

UDP报头包括4个字段，每个字段占用2个字节（即16个二进制位），标题短，开销小

UDP 头部包含了以下几个数据：

两个十六位的端口号，分别为源端口（可选字段）和目标端口
整个数据报文的长度
整个数据报文的检验和（IPv4 可选字段），该字段用于发现头部信息和数据中的错误

特点如下：

面向无连接：不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
不可靠性：首先不可靠性体现在无连接上，通信都不需要建立连接；，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。
有单播，多播，广播的功能： UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。
当包的到达顺序出现乱序时，UDP没有纠正的功能。
UDP 没有拥塞控制，一直会以恒定的速度发送数据，即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。
头部开销小，传输数据报文时是很高效的。 UDP 的头部开销小，只有8字节，相比 TCP 的至少20字节要少得多，在传输数据报文时是很高效的。

什么是TCP

TCP的全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 是面向连接的、可靠的流协议（流就是指不间断的数据结构）。

它有以下几个特点：

1）面向连接

面向连接，是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。

2）仅支持单播传输

每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

3）面向字节流

TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。

4）可靠传输

对于可靠传输，判断丢包、误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

5）提供拥塞控制

当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞。

6）提供全双工通信

TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

TCP和UDP区别

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输（数据顺序和正确性），使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用，例如视频会议、直播	适用于要求可靠传输的应用，例如文件传输

TCP面向连接，提供可靠的服务，UDP无连接，发送数据之前不需要建立连接，UDP不保证可靠交付
UDP具有较好的实时性，工作效率比TCP高，适合于高速传输和实时性要求高的应用场景
每一条TCP连接只能是一对一的，而UDP支持一对一，一对多，多对一和多对多交互通信
UDP首部字段开销小，TCP首部开销20字节
TCP面向字节流传输，将数据看成一连串无结构的字节流。而UDP面向报文，一次交付一个完整的报文，并且不可分割，报文是UDP数据报处理的最小单位

TCP和UDP的使用场景

TCP应用场景： 效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。例如：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
UDP应用场景： 效率要求相对高，对准确性要求相对低的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

UDP协议为什么不可靠？

UDP在传输数据之前不需要先建立连接，远地主机的运输层在接收到UDP报文后，不需要确认，提供不可靠交付。总结就以下四点：

不保证消息交付：不确认，不重传，无超时
不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
不跟踪连接状态：不必建立连接或重启状态机
不进行拥塞控制：不内置客户端或网络反馈机制

TCP三次握手

TCP 是面向连接的协议，所以使用 TCP 前必须先建立连接，而建立连接是通过三次握手来进行的。三次握手的过程如下图：

一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态

第一次握手：客户端向服务端发送一个 SYN 报文（SYN = 1），并指明客户端的初始化序列号 ISN(x)，即图中的 seq = x，表示本报文段所发送的数据的第一个字节的序号。此时客户端处于 SYN_SENT 状态。

客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。

2）第二次握手：服务器收到客户端的 SYN 报文之后，会发送 SYN 报文作为应答（SYN = 1），并且指定自己的初始化序列号 ISN(y)，即图中的 seq = y。同时会把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1，此时服务器处于 SYN_REVD 的状态。

服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。

3）第三次握手：客户端收到服务器端响应的 SYN 报文之后，会发送一个 ACK 报文，也是一样把服务器的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1（初始为 seq = x，所以第二个报文段要 +1），此时客户端处于 Establised 状态。

第三次握手是可以携带数据的，前两次握手是不可以携带数据的

服务器收到 ACK 报文之后，也处于 Establised 状态，至此，双方建立起了 TCP 连接。

为什么TCP三次握手

xiaolincoding.com/network/3_t…

因为通过三次握手，双方都确认了对方的发送和接收能力正常，建立了一个可靠的连接。

从更深层次的角度来看，以三个方面分析三次握手的原因：

三次握手才可以防止旧历史连接的初始化造成混乱（主要原因）
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

原因一：避免历史连接

我们来看看 RFC 793 (RFC(Request For Comments)-意即“请求注解”，包含了关于Internet的几乎所有重要的文字资料)指出的 TCP 连接使用三次握手的首要原因：

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.

简单来说，三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

我们考虑一个场景，客户端先发送了 SYN（seq = 90）报文，然后客户端宕机了，而且这个 SYN 报文还被网络阻塞了，服务端并没有收到，接着客户端重启后，又重新向服务端建立连接，发送了 SYN（seq = 100）报文（注意！不是重传 SYN，重传的 SYN 的序列号是一样的）。

看看三次握手是如何阻止历史连接的：

客户端连续发送多次 SYN（都是同一个四元组）建立连接的报文，在网络拥堵情况下：

一个「旧 SYN 报文」比「最新的 SYN」报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文中的确认号是 91（90+1）。
客户端收到后，发现自己期望收到的确认号应该是 100 + 1，而不是 90 + 1，于是就会回 RST 报文。
服务端收到 RST 报文后，就会释放连接。
后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。

上述中的**「旧 SYN 报文」称为历史连接**，TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。

原因二：同步双方初始序列号

TCP 协议的通信双方，都必须维护一个「序列号」，序列号是可靠传输的一个关键因素，它的作用：

接收方可以去除重复的数据；
接收方可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中，哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。

原因三：避免资源浪费

如果只有「两次握手」，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ****ACK ****报文，所以服务端每收到一个 ****SYN ****就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

TCP四次挥手

终止一个 TCP 连接要经过四次挥手。这是由于 TCP 的半关闭（half-close）特性造成的，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

客户端或服务端均可主动发起挥手动作。

回顾一下上图中符号的意思：

FIN ：连接终止位
seq：发送的第一个字节的序号
ACK：确认报文段
ack：确认号。希望收到的下一个数据的第一个字节的序号

刚开始双方都处于ESTABLISHED 状态，假设是客户端先发起关闭请求。四次挥手的过程如下：

1）第一次挥手：客户端发送一个 FIN 报文（请求连接终止：FIN = 1），报文中会指定一个序列号 seq = u。并停止再发送数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。

FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

CLOSE-WAIT - 等待从本地用户发来的连接中断请求；

此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待 2）状态，等待服务端发出的连接释放报文段。

FIN-WAIT-2 - 从远程TCP等待连接中断请求；

3）第三次挥手：如果服务端也想断开连接了（没有要向客户端发出的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；

4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答（ack = w+1），且把服务端的序列值 +1 作为自己 ACK 报文的序号值（seq=u+1），此时客户端处于 TIME_WAIT （时间等待）状态。

TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认；

🚨 注意！！！这个时候由服务端到客户端的 TCP 连接并未释放掉，需要经过时间等待计时器设置的时间 2MSL（一个报文的来回时间）后才会进入 CLOSED 状态（这样做的目的是确保服务端收到自己的 ACK 报文。如果服务端在规定时间内没有收到客户端发来的 ACK 报文的话，服务端会重新发送 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文给服务端）。服务端收到 ACK 报文之后，就关闭连接了，处于 CLOSED 状态。

等待2MSL时间后，客户端可以放心释放掉TCP占用的资源、端口号等等。

TCP为什么需要四次挥手

再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。

但是在特定情况下，四次挥手是可以变成三次挥手的具体情况可以看这篇：TCP 四次挥手，可以变成三次吗？(opens new window)

当被动关闭方（上图的服务端）在 TCP 挥手过程中，「没有数据要发送」并且「开启了 TCP 延迟确认机制」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。

什么是 TCP 延迟确认机制？

当发送没有携带数据的 ACK，它的网络效率也是很低的，因为它也有 40 个字节的 IP 头和 TCP 头，但却没有携带数据报文。为了解决 ACK 传输效率低问题，所以就衍生出了 TCP 延迟确认。

TCP 延迟确认的策略：

当有响应数据要发送时，ACK 会随着响应数据一起立刻发送给对方
当没有响应数据要发送时，ACK 将会延迟一段时间，以等待是否有响应数据可以一起发送
如果在延迟等待发送 ACK 期间，对方的第二个数据报文又到达了，这时就会立刻发送 ACK

TCP的流量控制机制

一般来说，流量控制就是为了让发送方发送数据的速度不要太快，要让接收方来得及接收。TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。这里说的窗口大小其实就是每次传输的数据大小。

当一个连接建立时，连接的每一端分配一个缓冲区来保存输入的数据，并将缓冲区的大小发送给另一端。
当数据到达时，接收方发送确认，其中包含了自己剩余的缓冲区大小。（剩余的缓冲区空间的大小被称为窗口，指出窗口大小的通知称为窗口通告。接收方在发送的每一确认中都含有一个窗口通告。）
如果接收方应用程序读数据的速度能够与数据到达的速度一样快，接收方将在每一确认中发送一个正的窗口通告。
如果发送方操作的速度快于接收方，接收到的数据最终将充满接收方的缓冲区，导致接收方通告一个零窗口。发送方收到一个零窗口通告时，必须停止发送，直到接收方重新通告一个正的窗口。

TCP滑动窗口的作用

TCP在进行数据传输的时候都是先将数据放在数据缓冲区中的，TCP维护了两个缓冲区，发送方缓冲区和接收方缓冲区。

发送方缓冲区：发送方缓冲区用于存储已经准备就绪数据和发送了但是没有被确认的数据。
接收方缓冲区：接收方缓冲区用于存储已经被接收但是还没有被用户进程消费的数据。

滑动窗口机制是TCP的一种流量控制方法，该机制允许发送方在停止并等待确认前连续发送多个分组，而不必每发送一个分组就停下来等待确认，从而增加数据传输的速率提高应用的吞吐量。

滑动窗口的大小意味着接受方还有多大的缓冲区用于接受数据，发送方可以通过滑动窗口的大小来确定应该发送多少字节数据。

TCP拥塞控制的作用

所谓拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制和流量控制都是太那个个控制发送方发送数据的速率来达到效果的。

区别在于：拥塞控制是让网络能够承受现有的网络负荷，它是一个全局性的过程，设计所有主机，路由器以及网络传输性能有关的所有因素。而流量控制往往是指点对点的通信量的控制，即接收端控制发送端，即抑制发送端发送数据的速率，以便使接收端来得及接收。

因此，发送方在确定发送报文段的速率时，既要根据接收方的接收能力，又要从全局考虑不要使网络发送拥塞，因此，TCP协议要求发送方维护两个窗口：

接收窗口rwnd，接收方根据目前接收缓存大小所设定的窗口值
拥塞窗口cwnd，发送方根据自己估算的网络拥塞程度设置的窗口值，反映了网络的当前容量。

发送窗口的上限取得是接收窗口rwnd和拥塞窗口cwnd中较小的一个，即min(rwnd,cwnd)

接受窗口根据TCP报文首部的窗口字段确定，拥塞窗口怎么维护呢？为了更好地对传输层进行拥塞控制，给出了下面四种算法：慢开始、拥塞避免、快重传、快恢复

TCP的拥塞控制机制

TCP的拥塞控制机制主要是以下四种机制：

慢启动（慢开始）
拥塞避免
快速重传
快速恢复

（1）慢启动（慢开始）

在开始发送的时候设置cwnd = 1（cwnd指的是拥塞窗口）
思路：开始的时候不要发送大量数据，而是先测试一下网络的拥塞程度，由小到大增加拥塞窗口的大小。
为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限(ssthresh 状态变量)

- 当cnwd < ssthresh，使用慢开始算法
- 当cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
- 当cnwd > ssthresh，使用拥塞避免算法

（2）拥塞避免

拥塞避免未必能够完全避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性增长，使网络不容易出现阻塞。
思路：让拥塞窗口cwnd缓慢的增大，即每经过一个返回时间RTT就把发送方的拥塞控制窗口加一
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如图所示: 其中，判断网络出现拥塞的根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理。

（3）快速重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)。发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量

（4）快速恢复

当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

滑动窗口和拥塞窗口的区别

滑动窗口： 接受数据端使用的窗口大小，用来告知发送端接收端的缓存大小，以此可以控制发送端发送数据的大小，从而达到流量控制的目的。

拥塞窗口cwnd，发送方根据自己估算的网络拥塞程度设置的窗口值，反映了网络的当前容量。

滑动窗口用于控制接收端的缓存大小，拥塞窗口用于控制当前网络的负载能力，解决的是网络传输中的拥堵问题

TCP 协议保证可靠传输的手段

应用数据被分割成 TCP 认为最适合发送的数据块。
TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
TCP 的接收端会丢弃重复的数据。
流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）
拥塞控制： 当网络拥塞时，减少数据的发送。
ARQ协议：自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。
超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

TCP粘包是怎么回事，如何处理?

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。粘包关系最大的就是基于字节流这个特点。应用层传到 TCP 协议的数据，不是以消息报为单位向目的主机发送，而是以字节流的方式发送到下游，这些数据可能被切割和组装成各种数据包，接收端收到这些数据包后没有正确还原原来的消息，因此出现粘包现象。

所谓粘包就是连续给对端发送两个或者两个以上的数据包，对端在一次收取中可能收到的数据包大于 1 个，大于 1 个，可能是几个（包括一个）包加上某个包的部分，或者干脆就是几个完整的包在一起。当然，也可能收到的数据只是一个包的部分，这种情况一般也叫半包。

产生tcp粘包的原因之一是：Nagle 算法，它是一种通过减少数据包的方式提高 TCP 传输性能的算法。

因为网络带宽有限，它不会将小的数据块直接发送到目的主机，而是会在本地缓冲区中等待更多待发送的数据，使用该算法也可能会导致应用层协议多次写入的数据被合并或者拆分发送，导致粘包问题。

如何解决

1）发送方

对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

（2）接收方

接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。

（2）应用层

应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？

格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

UDP会不会产生粘包问题

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

Https协议相关

segmentfault.com/a/119000002…

github.com/LinDaiDai/n…

什么是HTTPS

HTTP 在传输数据的过程中，所有的数据都是明文传输，没有安全性可言。HTTPS又称超文本传输安全协议，可以理解为 HTTPS = HTTP + 加密 + 认证 + 完整性保护，它不是一种新的应用层协议，而是在HTTP通信接口部分用SSL和TLS协议代替。

通常情况下，HTTP直接和TCP通信，使用SSL时，HTTP和SSL通信，SSL再和TCP通信。

采用 SSL 后， HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

需要注意的是，SSL是独立于HTTP的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术

HTTPS 的缺点：

在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
在现有的证书机制下，中间人攻击依然有可能发生。
HTTPS 需要更多的服务器资源，也会导致成本的升高。

SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。

针对HTTPS速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL 加速器这种（专用服务器）硬件来改善该问题。该硬件为 SSL 通信专用硬件，相对软件来讲，能够提高数倍 SSL 的计算速度。仅在 SSL处理时发挥 SSL 加速器的功效，以分担负载。

HTTP和HTTPS的区别

安全性：

- HTTPS 是通过在 HTTP 上加入 SSL/TLS 加密层来实现安全传输的。SSL/TLS 提供了加密通信和身份验证的功能，可以有效防止数据被窃听和篡改，以及确保通信双方的身份是可信的。
- HTTP 不具备加密功能，所有的数据传输都是明文的，容易被网络攻击者窃听和篡改。

使用 HTTPS 协议需要申请 CA 证书，一般免费证书较少，因而需要一定费用。
端口：

- HTTPS 默认使用 443 端口进行通信。
- HTTP 默认使用 80 端口进行通信。

HTTP 页面响应速度比 HTTPS 快，这个很好理解，由于加了一层安全层，建立连接的过程更复杂，也要交换更多的数据，难免影响速度。
性能消耗：与HTTP的纯文本通信相比，HTTPS的加密通信会消耗更多的CPU及内存资源，同等时间可处理的请求数会减少，因此HTTPS更加耗费服务器资源。
URL 前缀：

- 在 URL 前面，HTTPS 使用 https:// 前缀。
- 在 URL 前面，HTTP 使用 http:// 前缀。

当使用HTTPS时，网站在Google中的排名会提高，而使用HTTP时，不会获得任何排名提升。

对称加密与非对称加密

HTTPS 解决数据传输安全问题的方案就是使用加密算法，具体来说是混合加密算法，也就是对称加密和非对称加密的混合使用，这里有必要先了解一下这两种加密算法的区别和优缺点。

对称加密

对称密钥加密是指加密和解密同用一个密钥，也被叫做共享密钥加密（ Common keycrypto system）

常见的对称加密算法有 DES、3DES 和 AES 等，其优缺点如下：

优点：算法公开、计算量小、加密速度快、加密效率高，适合加密比较大的数据。
缺点：

1. 交易双方需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。
2. 每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信双方所拥有的钥匙数量急剧增长，密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。

但是有一个致命的问题，那就是既然双方要使用相同的密钥，那就必然要在传输数据之前先由一方把密钥传给另一方，那么在此过程中密钥就很有可能被截获，这样一来加密的数据也会被轻松解密。那如何确保密钥在传输过程中的安全呢？这就要用到非对称加密了。

非对称加密

非对称加密，顾名思义，就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用非对称加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

常用的非对称加密算法是 RSA 算法，想详细了解的同学点这里：RSA 算法详解一、RSA 算法详解

其优缺点如下：

优点：算法公开，加密和解密使用不同的钥匙，私钥不需要通过网络进行传输，安全性很高。
缺点：计算量比较大，加密和解密速度相比对称加密慢很多。

由于非对称加密的强安全性，可以用它完美解决对称加密的密钥泄露问题，效果图如下：

在上述过程中，客户端在拿到服务器的公钥后，会生成一个随机码 (用 KEY 表示，这个 KEY 就是后续双方用于对称加密的密钥)，然后客户端使用公钥把 KEY 加密后再发送给服务器，服务器使用私钥将其解密，这样双方就有了同一个密钥 KEY，然后双方再使用 KEY 进行对称加密交互数据。在非对称加密传输 KEY 的过程中，即便第三方获取了公钥和加密后的 KEY，在没有私钥的情况下也无法破解 KEY (私钥存在服务器，泄露风险极小)，也就保证了接下来对称加密的数据安全。而上面这个流程图正是 HTTPS 的雏形，HTTPS 正好综合了这两种加密算法的优点，不仅保证了通信安全，还保证了数据传输效率。

HTTPS采用混合加密机制

HTTPS 采用（对称加密）共享密钥加密和（非对称加密）公开密钥加密两者并用的混合加密机制。非对称加密与对称加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

什么是数字签名

数字签名的产生主要就是为了解决HTTP中内容可能被篡改的问题，即校验数据的完整性。它能确定消息是发送方发送过来的，因为这里会有一个验证数字签名的过程，别人是假冒不了发送方的签名的。

数字签名它是什么呢？它的产生过程其实就是两步，第一步将原文用Hash函数生成一个叫消息摘要的东西，第二步就是用发送方的私钥对这个消息摘要进行进行加密。这个产生的东西就叫做数字签名，它一般会与原文一起发送给接收者。

而验证它的过程其实也并不复杂。

首先发送方会将原文与数字签名(也就是加密后的摘要)一起发送给接收方

接收方会接收到这两样东西，即原文和数字签名

接收方用Hash函数处理原文会得到一份消息摘要

同时用发送方的公钥解密数字签名也会得到一份消息摘要

只要比较这两份消息摘要是否相等就可以验证出数据有没有被篡改了

当然这里关键的一步就是要保证发送方传递过来的公钥是可信赖的，这时候就得用到数字证书了。

什么是数字证书

数字证书 (digital certificate)： 在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信，这就是传说中的“中间人攻击”(man in the middle attack)。数字证书的本质就是确保公开密钥的真实性， 解决此问题的方法是通过受信任的第三方交换公钥，具体做法就是服务器不直接向客户端发送公钥，而是要求受信任的第三方，也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。数字证书一般包含以下内容：

1. 证书所有者的公钥
2. 证书所有者的专有名称
3. 证书颁发机构的专有名称
4. 证书的有效起始日期
5. 证书的过期日期
6. 证书数据格式的版本号
7. 序列号，这是证书颁发机构为该证书分配的唯一标识符... ...

服务器首先使用一种 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用认证中心的私钥对消息摘要加密，形成数字签名。最后将原始的信息和签名合在一起，称为数字证书。当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和生成的摘要进行对比，就能发现得到的信息是否被更改了。

这个方法最要的是认证中心的可靠性，一般浏览器里会内置一些顶层的认证中心的证书，相当于我们自动信任了他们，只有这样才能保证数据的安全。

①服务器把自己的公开密钥登录至数字证书认证机构

②数字证书认证机构用自己的私有密钥向服务器的公开密码署数字签名并颁发公钥证书

③客户端拿到服务器的公钥证书后，使用数字证认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开密钥的真实性

什么是证书链

证书链，也称为证书路径，是用于认证实体合法身份的证书列表，具体到 HTTPS 通信中，就是为了验证服务器的合法身份。之所以使用证书链，是为了保证根证书 (root CA certificate)的安全，中间层可以看做根证书的代理，起到了缓冲的作用，

证书链从根证书开始，并且证书链中的每一级证书所标识的实体都要为其下一级证书签名，而根证书自身则由证书颁发机构签名。客户端在验证证书链时，必须对链中所有证书的数字签名进行验证，直到达到根证书为止。

HTTPS加密过程

HTTPS 的整个通信过程可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为非对称加密和对称加密两个阶段。具体流程按图中的序号讲解。

segmentfault.com/img/bVbClUl

1.客户端请求HTTPS网址，连接到服务端的443端口，请求内容包含客户端SSL版本号，加密套件列表（所使用的加密算法及密钥长度等）等信息发送给服务器

2.采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书，证书是需要申请的，并由数字证书认证机构(CA)通过审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。

3.服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。

4.客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。

5.客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。

6.服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。

7.服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。

8.双方使用对称加密愉快地传输所有数据。

SSL/TLS握手过程

SSL / TLS 握手详细过程

"client hello"消息： 客户端通过发送"client hello"消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择，还有一个"client random"随机字符串。
"server hello"消息： 服务器发送"server hello"消息对客户端进行回应，该消息包含了数字证书，服务器选择的密码组合和"server random"随机字符串。
验证： 客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：

1. 检查数字签名
2. 验证证书链 (这个概念下面会进行说明)
3. 检查证书的有效期
4. 检查证书的撤回状态 (撤回代表证书已失效)

"premaster secret"字符串： 客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)"，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。
使用私钥： 服务器使用私钥解密"premaster secret"。
生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
客户端就绪： 客户端发送经过共享密钥 KEY加密过的"finished"信号。
服务器就绪： 服务器发送经过共享密钥 KEY加密过的"finished"信号。
达成安全通信： 握手完成，双方使用对称加密进行安全通信。

HTTPS如何保证传输安全

加密、身份认证、数据完整性

其中加密可以依靠对称加密和非对称加密两种方式完成

身份认证依靠数字证书来进行身份验证：客户端第一次给服务端发送HTTPS请求的时候，服务端会将它自己的证书随着其它的信息(例如需要使用的加密套件等东西)一起返给客户端。客户端在收到之后首先会验证这个证书，只有验证通过之后才会有后续操作。而验证的过程其实也就是数字签名的验证过程：

前面说过了，证书其实是由明文信息(申请者的公钥，组织信息，个人信息以及认证机构自己的信息等)和这个明文信息的数字签名组成的。(对应着题5也就是原文和数字签名)
客户端会用Hash函数处理明文信息生成一个信息摘要
然后再用内置在浏览器上的CA的公钥来解密证书里的数字签名，得到一个信息摘要。因为我们知道证书实际是由CA颁发给服务器的，并且里面的数字签名也是用的CA的私钥加密的，所以只有CA的公钥才能解。
最后再将两个信息摘要进行对比，若是一样则能保证通信方的身份是正确的。

其实验证证书的过程不仅仅是数字签名的验证，客户端还会验证证书相关的域名信息，有效时间，是不是在CRL吊销列表里，以及它的上一级是否有效等等。

数据完整性依靠数字签名完成

结合两种加密⽅式，将对称加密的密钥使⽤⾮对称加密的公钥进⾏加密，然后发送出去，接收⽅使⽤私钥进⾏解密得到对称加密的密钥，然后双⽅可以使⽤对称加密来进⾏沟通。

此时⼜带来⼀个问题，中间⼈问题：

如果此时在客户端和服务器之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中间⼈就可以轻松解密通信双⽅所发送的所有数据。

所以这个时候需要⼀个安全的第三⽅颁发证书（CA），证明身份的身份，防⽌被中间⼈攻击。证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的HASH算法、证书到期时间等。

但是问题来了，如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技术，数字签名。

数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。这个时候就能最⼤程度保证通信的安全了。

为什么不一直使用HTTPS

与纯文本通信相比，加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。

因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。

特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。

HTTPS绝对安全吗

不是绝对安全的，可以通过中间人攻击。

什么是中间人攻击

中间人攻击是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

HTTPS 使用了 SSL 加密协议，是一种非常安全的机制，目前并没有方法直接对这个协议进行攻击，一般都是在建立 SSL 连接时，拦截客户端的请求，利用中间人获取到 CA 证书、非对称加密的公钥、对称加密的密钥；有了这些条件，就可以对请求和响应进行拦截和篡改。

过程原理：

本地请求被劫持（如 DNS 劫持等），所有请求均发送到中间人的服务器
中间人服务器返回中间人自己的证书
客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
中间人以客户端的请求内容再向官方网站发起请求
因为中间人与服务器的通信过程是合法的，官方网站通过建立的安全通道返回加密后的数据
中间人凭借与官方网站建立的对称加密算法对内容进行解密
中间人通过与客户端建立的对称加密算法对官方内容返回的数据进行加密传输
客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

HTTPS可以抓包吗

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。

但是，我们可以通过抓包工具来抓包。它的原理其实是模拟一个中间人。

通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

关于 httpps 抓包的原理可以看这一篇文章。

Android平台HTTPS抓包解决方案及问题分析

有人可能会问了，既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？

HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被 pojie。

DNS介绍

DNS 协议是什么

DNS（Domain Name System，域名系统）是一个用于将域名转换为与之对应的 IP 地址的分布式数据库系统。

DNS 协议提供通过域名查找 IP 地址，或逆向从 IP 地址反查域名的服务

将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。

DNS同时使用TCP和UDP协议？

DNS占用53号端口，同时使用TCP和UDP协议。

在域名解析的时候使用UDP协议

客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

如果 DNS 查询的响应超过了 UDP 包的最大限制（通常是512字节），则会使用 TCP 协议进行传输。其他一些特殊情况，如区域传输（zone transfer）和 DNSSEC（DNS Security Extensions）的验证等也可能使用 TCP 协议。

DNS完整的查询过程

DNS服务器解析域名的过程：

首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步
查询本地 DNS 服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果
本地DNS服务器将返回结果保存在缓存中，便于下次使用
本地DNS服务器将返回结果返回给浏览器

比如要查询 www.baidu.com 的 IP 地址，首先会在浏览器的缓存中查找是否有该域名的缓存，如果不存在就将请求发送到本地的 DNS 服务器中，本地DNS服务器会判断是否存在该域名的缓存，如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表。然后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表。

迭代查询与递归查询

DNS解析是一个包含迭代查询和递归查询的过程。

递归查询指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归查询，用户只需要发出一次查询请求。
迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出多次的查询请求。

一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我们最终的请求结果。而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地 DNS 服务器自己进行。

DNS 记录和报文

DNS 服务器中以资源记录的形式存储信息，每一个 DNS 响应报文一般包含多条资源记录。一条资源记录的具体的格式为

（Name，Value，Type，TTL）

其中 TTL 是资源记录的生存时间，它定义了资源记录能够被其他的 DNS 服务器缓存多长时间。

常用的一共有四种 Type 的值，分别是 A、NS、CNAME 和 MX ，不同 Type 的值，对应资源记录代表的意义不同：

如果 Type = A，则 Name 是主机名，Value 是主机名对应的 IP 地址。因此一条记录为 A 的资源记录，提供了标准的主机名到 IP 地址的映射。
如果 Type = NS，则 Name 是个域名，Value 是负责该域名的 DNS 服务器的主机名。这个记录主要用于 DNS 链式查询时，返回下一级需要查询的 DNS 服务器的信息。
如果 Type = CNAME，则 Name 为别名，Value 为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名对应的规范主机名，从而告诉查询主机去查询这个主机名的 IP 地址。主机别名主要是为了通过给一些复杂的主机名提供一个便于记忆的简单的别名。
如果 Type = MX，则 Name 为一个邮件服务器的别名，Value 为邮件服务器的规范主机名。它的作用和 CNAME 是一样的，都是为了解决规范主机名不利于记忆的缺点。

在浏览器地址栏输入URL，按下回车后发生了什么

简单的分析，从输入 URL到回车后发生的行为如下：

URL解析
DNS 查询
TCP 连接
发送HTTP 请求
响应请求
页面渲染

URL解析：首先判断你输入的是一个合法的 URL 还是一个待搜索的关键词，并且根据你输入的内容进行对应操作。如果是搜索内容，那么将搜索内容+默认搜索引擎形成新的URL；如果输入内容符合URL规则，则形成合法的URL并继续执行。

DNS查询：将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。具体查询过程如下：

首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步
查询本地 DNS 服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果
本地DNS服务器将返回结果保存在缓存中，便于下次使用
本地DNS服务器将返回结果返回给浏览器

建立TCP连接：进行三次握手，指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN，此时客户端处于 SYN_SEND 状态。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

发送HTTP 请求：浏览器需要请求网页所需的资源，在这个过程中，浏览器会执行“浏览器缓存机制”的一系列操作。浏览器会首先检查本地缓存，也就是强制缓存过程：强制缓存规则如下：控制强制缓存的字段分别是Expires（HTTP1.0）和Cache-Control（HTTP1.1），其中Cache-Control优先级比Expires高。Expires的值为服务器返回该请求结果缓存的到期时间，即再次发起该请求时，如果客户端的时间小于Expires的值时，直接使用缓存结果。

到了HTTP/1.1，Expires已经被Cache-Control替代，Cache-Control为max-age=600，意思就是说在600秒内再次发起该请求，则会直接使用缓存结果，强制缓存生效。

如强制缓存失效，则执行协商缓存：

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程。控制协商缓存的字段分别有：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。

Last-Modified是服务器响应请求时，返回该资源文件在服务器最后被修改的时间。If-Modified-Since则是客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求，发现请求头含有If-Modified-Since字段，则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则则返回304，代表资源无更新，可继续使用缓存文件，

Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)。If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200。

若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，重新获取请求结果，再存入浏览器缓存中；生效则返回304，继续使用缓存。

响应请求：服务器在响应请求的过程中，可能涉及到反向代理服务器，是一种位于客户端和原始服务器之间的服务器，它接收客户端的请求并将请求转发到一个或多个后端服务器，然后将后端服务器的响应返回给客户端，就好像这些响应来自于代理服务器自身一样。反向代理服务器可以根据负载情况将请求分发到多个后端服务器，从而实现负载均衡，提高系统的性能和可靠性。

在服务器响应之后，由于现在http默认开始长连接keep-alive，当页面关闭之后，tcp链接则会经过四次挥手完成断开。四次挥手的具体过程如下：

客户端发送连接释放请求：

- 客户端向服务器发送一个连接释放请求，即发送一个 FIN（Finish）报文段，表示客户端不再发送数据，但仍然可以接收数据。

服务器确认收到连接释放请求：

- 服务器收到客户端的 FIN 报文段后，向客户端发送一个确认报文段，即发送一个 ACK（Acknowledgment）报文段，确认收到了客户端的连接释放请求。服务器此时进入 CLOSE_WAIT 状态。

服务器发送连接释放请求：

- 服务器在发送完所有数据后，也准备关闭连接。服务器向客户端发送一个连接释放请求，即发送一个 FIN 报文段，表示服务器不再发送数据，但仍然可以接收数据。

客户端确认收到连接释放请求并发送确认：

- 客户端收到服务器的 FIN 报文段后，向服务器发送一个确认报文段，即发送一个 ACK 报文段，确认收到了服务器的连接释放请求。客户端此时进入 TIME_WAIT 状态。

在 TIME_WAIT 状态持续时间结束后，客户端关闭连接。

页面渲染：当浏览器接收到服务器响应的资源后，首先会对资源进行解析

查看响应头的信息，根据不同的指示做对应处理，比如重定向，存储cookie，解压gzip，缓存资源等等

查看响应头的 Content-Type的值，根据不同的资源类型采用不同的解析方式

页面的渲染过程如下：

解析HTML文档构建成DOM树；
解析过程中遇到style标签、link元素等CSS内容构建成CSSOM树；
将DOM 树和 CSSOM 树合成渲染树；
根据渲染树进行页面元素的布局；
对布局树进行分层，并生成分层树；
为每个图层单独产生绘制指令集，之后将每个图层的绘制信息提交给合成线程
分块：合成线程将图层分成不同的图块
光栅化：对图块进行光栅化，生成一块一块的位图
画 draw：合成线程根据位图生成指引信息，提交给GPU进程进行屏幕成像

WebSocket

1. 对 WebSocket 的理解

WebSocket是HTML5提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于TCP传输协议，并复用HTTP的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。

WebSocket原理：客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。

WebSocket 特点的如下：

支持双向通信，实时性更强
可以发送文本，也可以发送二进制数据‘’
建立在TCP协议之上，服务端的实现比较容易
数据格式比较轻量，性能开销小，通信高效
没有同源限制，客户端可以与任意服务器通信
协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

优点

较少的控制开销：数据包头部协议较小，不同于http每次请求需要携带完整的头部
更强的实时性：相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少
保持创连接状态：创建通信后，可省略状态信息，不同于HTTP每次请求需要携带身份验证
更好的二进制支持：定义了二进制帧，更好处理二进制内容
支持扩展：用户可以扩展websocket协议、实现部分自定义的子协议
更好的压缩效果：Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率

基于websocket的事实通信的特点，其存在的应用场景大概有：

弹幕
媒体聊天
协同编辑
基于位置的应用
体育实况更新
股票基金报价实时更新

Websocket的使用方法如下：

在客户端中：

javascript
复制代码// 在index.html中直接写WebSocket，设置服务端的端口号为 9999
let ws = new WebSocket('ws://localhost:9999');
// 在客户端与服务端建立连接后触发
ws.onopen = function() {
    console.log("Connection open."); 
    ws.send('hello');
};
// 在服务端给客户端发来消息的时候触发
ws.onmessage = function(res) {
    console.log(res);       // 打印的是MessageEvent对象
    console.log(res.data);  // 打印的是收到的消息
};
// 在客户端与服务端建立关闭后触发
ws.onclose = function(evt) {
  console.log("Connection closed.");
};

2. 即时通讯的实现：短轮询、长轮询、SSE 和 WebSocket 间的区别？

短轮询和长轮询的目的都是用于实现客户端和服务器端的一个即时通讯。

短轮询的基本思路： 浏览器每隔一段时间向浏览器发送 http 请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。这种方式的优点是比较简单，易于理解。缺点是这种方式由于需要不断的建立 http 连接，严重浪费了服务器端和客户端的资源。当用户增加时，服务器端的压力就会变大，这是很不合理的。

长轮询的基本思路： 首先由客户端向服务器发起请求，当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则到达一定的时间限制才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。长轮询和短轮询比起来，它的优点是明显减少了很多不必要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，连接挂起也会导致资源的浪费。

SSE 的基本思想： 服务器使用流信息向服务器推送信息。严格地说，http 协议无法做到服务器主动推送信息。但是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会连续不断地发送过来。这时，客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机制，使用流信息向浏览器推送信息。它基于 http 协议，目前除了 IE/Edge，其他浏览器都支持。它相对于前面两种方式来说，不需要建立过多的 http 请求，相比之下节约了资源。

WebSocket 是 HTML5 定义的一个新协议议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息，而 SSE 的方式是单向通信的，只能由服务器端向客户端推送信息，如果客户端需要发送信息就是属于下一个 http 请求了。

上面的四个通信协议，前三个都是基于HTTP协议的。

对于这四种即使通信协议，从性能的角度来看： WebSocket > 长连接（SEE） > 长轮询 > 短轮询 但是，我们如果考虑浏览器的兼容性问题，顺序就恰恰相反了： 短轮询 > 长轮询 > 长连接（SEE） > WebSocket 所以，还是要根据具体的使用场景来判断使用哪种方式。

Socket和WebSocket的关系

Socket是对TCP/IP协议的封装和应用，Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。而Websocket 通信是通过 HTTP 的握手过程实现的。他们两个没有关系，和Java与JavaScript类似。