计算机网络理论知识
说一下HTTP和HTTPS
HTTPS的SSL加密是在传输层实现的。
基本概念
- HTTP： 超文本传输协议，是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从 WWW 服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
- HTTPS：是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。
- HTTPS协议的主要作用：建立一个信息安全通道，来确保数组的传输，确保网站的真实性。
区别
HTTP数据都是未加密的，也就是明文的，网景公司设置了 SSL 协议来对 HTTP协议传输的数据进行加密处理，简单来说 HTTPS 协议是由 HTTP 和 SSL 协议构建的可进行加密传输和身份认证的网络协议，比HTTP 协议安全性更高
主要区别
- HTTPS协议需要ca证书，费用较高
- HTTP是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议。
- 使用不同的链接方式，端口也不同，一般而言，HTTP 协议的端口为 80，HTTPS 的端口为 443
- HTTP连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP安全。
工作原理
客户端在使用 HTTPS 方式与 Web 服务器通信时有以下几个步骤
- 客户端使用https url访问服务器，则要求 web 服务器建立 ssl 链接。
- web 服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），返回或者说传输给客户端。
- 客户端和 web 服务器端开始协商 SSL 链接的安全等级，也就是加密等级。
- 客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
- web 服务器通过自己的私钥解密出会话密钥。
- web 服务器通过会话密钥加密与客户端之间的通信。
HTTPS的优点
- 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
- HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
- HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
- 谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起同等 HTTP 网站，采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。
HTTPS的缺点
- https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。
- https 缓存不如 http 高效，会增加数据开销。 SSL 证书也需要钱，功能越强大的证书费用越高。
- SSL 证书需要绑定 IP，不能再同一个 ip 上绑定多个域名，ipv4 资源支持不了这种消耗。
HTTP 支持的方法
- GET
- POST
- HEAD
- OPTIONS
- PUT
- DELETE
- TRACE
- CONNECT
Get和Post的区别
- get 参数通过 url 传递，post 放在 request body 中。
- get 请求在 url 中传递的参数是有长度限制的，而 post 没有。
- get 比 post 更不安全，因为参数直接暴露在 url 中，所以不能用来传递敏感信息。
- get 请求只能进行 url 编码，而 post 支持多种编码方式
- get会将数据缓存起来，而post不会
- get 请求参数会被完整保留在浏览历史记录里，而 post 中的参数不会被保留。
- GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器 的限制，导致他们在应用过程中体现出一些不同。 GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。
HTTP请求的方式_HEAD方式
head：类似于 get 请求，只不过返回的响应中没有具体的内容，用户获取报头 options：允许客户端查看服务器的性能，比如说服务器支持的请求方式等等。
HTTP2.0
简要概括：http2.0 是基于 1999 年发布的 http1.0 之后的首次更新
- 提升访问速度（可以对于，请求资源所需时间更少，访问速度更快，相比 http1.0）
- 允许多路复用：多路复用允许同时通过单一的 HTTP/2 连接发送多重请求-响应信息。
- 改善了：在 http1.1 中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制（连接数量），超过限制会被阻塞。
- 二进制分帧：HTTP2.0 会将所有的传输信息分割为更小的信息或者帧，并对他们进行二进制编码首部压缩服务器端推送
HTTP常用请求头
| 协议头 | 说明 |
|---|---|
| Accept | 可接受的响应内容类型（Content-Types） |
| Accept-Charset | 可接受的字符集 |
| Accept-Encoding | 可接受的响应内容的编码方式 |
| Accept-Language | 可接受的响应内容语言列表 |
| Accept-Datetime | 可接受的按照时间来表示的响应内容版本 |
| Authorization | 用于表示 HTTP 协议中需要认证资源的认证信息 |
| Cache-Control | 用来指定当前的请求/回复中的，是否使用缓存机制。 |
| Connection | 客户端（浏览器）想要优先使用的连接类型 |
| Cookie | 由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie |
| Content-Length | 以 8 进制表示的请求体的长度 |
| Content-MD5 | 请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果 |
| Content-Type | 请求体的 MIME 类型 （用于 POST 和 PUT 请求 |
| Date | 发送该消息的日期和时间（以 RFC 7231 中定义的"HTTP 日期"格式 来发送） |
| Expect | 表示客户端要求服务器做出特定的行为 |
| Form | 发起此请求的用户的邮件地址 |
| Host | 表示服务器的域名以及服务器所监听的端口号。如果所请求的端口 是对应的服务的标准端口（80），则端口号可以省略。 |
| If-Match | 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对 应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新 某个资源后，该资源未被修改的情况下，才更新该资源。 |
| If-Modified-Since | 允许在对应的资源未被修改的情况下返回 304 未修改 |
| If-None-Match | 允许在对应的内容未被修改的情况下返回 304 未修改（ 304 Not Modified ），参考 超文本传输协议 的实体标 |
| If-Range | 如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否 则，返回整个新的实体 |
| If-Unmodified-Since | 仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。 |
| Max-Forwards | 限制该消息可被代理及网关转发的次数。 |
| Origin | 发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加 入一个 Access-Control-Allow-Origin 的消息头，表示访问控制所允许 的来源）。 |
| Pragma | 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产 生。 |
| Proxy-Authorization | 用于向代理进行认证的认证信息。 |
| Range | 表示请求某个实体的一部分，字节偏移以 0 开始。 |
| Referer | 表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接 将浏览器带到了当前页面。Referer 其实是 Referrer 这个单词，但 RFC 制作标准时给拼错了，后来也就将错就错使用 Referer 了。 |
| TE | 浏览器预期接受的传输时的编码方式：可使用回应协议头 Transfer-Encoding 中的值（还可以使用"trailers"表示数据传输时的分 块方式）用来表示浏览器希望在最后一个大小为 0 的块之后还接收 到一些额外的字段。 |
| User-Agent | 浏览器的身份标识字符串 |
| Upgrade | 要求服务器升级到一个高版本协议。 |
| Via | 告诉服务器，这个请求是由哪些代理发出的。 |
| Warning | 一个一般性的警告，表示在实体内容体中可能存在错误。 |
HTTP返回码
1XX
| 返回码 | 状态码英文 | 描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更 高级的协议，例如，切换到 HT |
2XX
| 返回码 | 状态码英文 | 描述 |
|---|---|---|
| 200 | OK | 请求成功。一般用于 GET 与 POST 请求 |
| 201 | Created | 创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的 meta 信息不在原 始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下， 可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文 档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分 GET 请求 |
3XX
| 返回码 | 状态码英文 | 描述 |
|---|---|---|
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特 征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新 URI，返回信息会 包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替 |
| 302 | Found | 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有 URI |
| 303 | See Other | 查看其它地址。与 301 类似。使用 GET 和 POST 请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回 任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返 回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经废弃的HTPP状态码 |
| 307 | Temporaty Redirrect | 临时重定向。与 302 类似。使用 GET 请求重定向 400 Bad Request 客户端请求的语法错误，服务器无法理解 |
4XX
| 返回码 | 状态码英文 | 描述 |
|---|---|---|
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站 设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authenticaltion | 请求要求代理的身份认证，与 401 类似，但请求者 应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求是可能返回此代码，服务器处理请求时发 生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410 不同于 404，如果资源以前有现在被永 久删除了可使用 410 代码，网站设计人员可通过 301 代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带 Content-Length 的请求信 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。 为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则 会包含一个 Retry-After |
| 414 | Request-URI Too Large | 请求URL过长（URL通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器不支持请求的功能，无法完成请求 |
5XX
| 返回码 | 状态码英文 | 描述 |
|---|---|---|
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad GateWay | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接到一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。 延时的长度可包含在服务器的 Retry-After 头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的 HTTP 协议的版本，无法完成处 理 |
对比 304 和 200
状态码 304：如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的 内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态 码。即客户端和服务器端只需要传输很少的数据量来做文件的校验，如果文件没有修改 过，则不需要返回全量的数据。
状态码 200：请求已成功，请求所希望的响应头或数据体将随此响应返回。即返回的数 据为全量的数据，如果文件不通过 GZIP 压缩的话，文件是多大，则要有多大传输量。
301和302的区别
- 301 Moved Permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引 用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应 当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
- 302 Found 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的， 客户端应当继续向原有地址发送以后的请求。只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可缓存的
字面上的区别就是 301 是永久重定向，而 302 是临时重定向。 301 比较常用的场景是使用域名跳转。302 用来做临时跳转 比如未登陆的用户访问用户 中心重定向到登录页面。
HTTP强缓存和协商缓存
缓存分为两种：强缓存和协商缓存（弱缓存），根据响应的 header 内容来决定
| 获取资源的形式 | 状态码 | 发送请求到服务器 | |
|---|---|---|---|
| 强缓存 | 从缓存取 | 200（from cache） | 否，直接从缓存取 |
| 协商缓存 | 从缓存取 | 304（not modified） | 是通过服务器来告知缓存是否可用 |
- 强缓存相关字段有
expires，cache-control。如果 cache-control 与 expires 同时存在的话， cache-control 的优先级高于 expires - 协商缓存相关字段有
Last-Modified/If-Modified-Since，Etag/If-None-Match
强缓存、协商缓存什么时候用哪个
因为服务器上的资源不是一直固定不变的，大多数情况下它会更新，这个时候如果我们 还访问本地缓存，那么对用户来说，那就相当于资源没有更新，用户看到的还是旧的资 源；所以我们希望服务器上的资源更新了浏览器就请求新的资源，没有更新就使用本地 的缓存，以最大程度的减少因网络请求而产生的资源浪费。
浏览器缓存
浏览器缓存是浏览器在本地磁盘对用户最近请求过的文档进行存储，当访问者再次访问同一页面时，浏览器就可以直接从本地磁盘加载文档。
所以根据上面的特点，浏览器缓存有下面的优点：
- 减少冗余的数据传输
- 减少服务器负担
- 加快客户端加载网页的速度
浏览器缓存是Web性能优化的重要方式。那么浏览器缓存的过程究竟是怎么样的呢？
在浏览器第一次发起请求时，本地无缓存，向web服务器发送请求，服务器起端响应请求，浏览器端缓存。过程如下：
在第一次请求时，服务器会将页面最后修改时间通过Last-Modified标识由服务器发送给客户端，客户端记录修改时间；服务器还会生成一个Etag，并发送给客户端。
浏览器后续再次进行请求时：
浏览器缓存主要分为强强缓存（也称本地缓存）和协商缓存（也称弱缓存）。根据上图，浏览器在第一次请求发生后，再次发送请求时：
- 浏览器请求某一资源时，会先获取该资源缓存的header信息，然后根据header中的
Cache-Control和Expires来判断是否过期。若没过期则直接从缓存中获取资源信息，包括缓存的header的信息，所以此次请求不会与服务器进行通信。这里判断是否过期，则是强缓存相关。后面会讲Cache-Control和Expires相关。 - 如果显示已过期，浏览器会向服务器端发送请求，这个请求会携带第一次请求返回的有关缓存的header字段信息，比如客户端会通过
If-None-Match头将先前服务器端发送过来的Etag发送给服务器，服务会对比这个客户端发过来的Etag是否与服务器的相同，若相同，就将If-None-Match的值设为false，返回状态304，客户端继续使用本地缓存，不解析服务器端发回来的数据，若不相同就将If-None-Match的值设为true，返回状态为200，客户端重新机械服务器端返回的数据；客户端还会通过If-Modified-Since头将先前服务器端发过来的最后修改时间戳发送给服务器，服务器端通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，则返回最新的内容，如果是最新的，则返回304，客户端继续使用本地缓存。
::: Tips 以下引用自思否 作者：puhongru 文章：HTTP强缓存和协商缓存 - JavaScript学习笔记 - SegmentFault 思否 :::
强缓存
强缓存是利用http头中的Expires和Cache-Control两个字段来控制的，用来表示资源的缓存时间。强缓存中，普通刷新会忽略它，但不会清除它，需要强制刷新。浏览器强制刷新，请求会带上Cache-Control:no-cache和Pragma:no-cache
Expires
Expires是http1.0的规范，它的值是一个绝对时间的GMT格式的时间字符串。如我现在这个网页的Expires值是：expires:Fri, 14 Apr 2017 10:47:02 GMT。这个时间代表这这个资源的失效时间，只要发送请求时间是在Expires之前，那么本地缓存始终有效，则在缓存中读取数据。所以这种方式有一个明显的缺点，由于失效的时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，就会导致缓存混乱。如果同时出现Cache-Control:max-age和Expires，那么max-age优先级更高。如我主页的response headers部分如下：
cache-control:max-age=691200
expires:Fri, 14 Apr 2017 10:47:02 GMT
那么表示资源可以被缓存的最长时间为691200秒，会优先考虑max-age。
Cache-Control
Cache-Control是在http1.1中出现的，主要是利用该字段的max-age值来进行判断，它是一个相对时间，例如Cache-Control:max-age=3600，代表着资源的有效期是3600秒。cache-control除了该字段外，还有下面几个比较常用的设置值：
- no-cache：不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
- no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
- public：可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。
- private：只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。 Cache-Control与Expires可以在服务端配置同时启用，同时启用的时候Cache-Control优先级高。
协商缓存
协商缓存就是由服务器来确定缓存资源是否可用，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问。
普通刷新会启用弱缓存，忽略强缓存。只有在地址栏或收藏夹输入网址、通过链接引用资源等情况下，浏览器才会启用强缓存，这也是为什么有时候我们更新一张图片、一个js文件，页面内容依然是旧的，但是直接浏览器访问那个图片或文件，看到的内容却是新的。
这个主要涉及到两组header字段：Etag和If-None-Match、Last-Modified和If-Modified-Since。上面以及说得很清楚这两组怎么使用啦~复习一下：
Etag和If-None-Match
Etag/If-None-Match返回的是一个校验码。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据浏览器上送的If-None-Match值来判断是否命中缓存。
与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。
Last-Modify/If-Modify-Since
浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。
当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。
如果命中缓存，则返回304，并且不会返回资源内容，并且不会返回Last-Modify。
为什么要有Etag
你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：
- 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
- 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
- 某些服务器不能精确的得到文件的最后修改时间。
Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。
另外觉得一篇很好的文章，从缓存策略来学习HTTP缓存：HTTP基于缓存策略三要素分解法
TCP三次握手
TCP三次握手
客户端和服务端都需要直到各自可收发，因此需要三次握手。
从图片可以得到三次握手可以简化为：C 发起请求连接 | S 确认，发起连接 | C 确认
双方要连接，要等待对端同意并返回确认，一端请求后收到确认包就意味着，网络可达并且对端同意建立连接。最后的模型则是
A --请求--> B
A <--确认-- B
A <--请求-- B
A --确认--> B
中间两次可以一起返回，所以是三次握手
引自知乎@Manistein
三次握手的作用
过程
- 第一次握手：客户端主动链接服务器，发送初始序列号
seq=x与SYN=1同步请求标志，并进入同步已发送SYN_SENT状态，等待服务器确认。 - 第二次握手：服务端收到消息后发送确认标志
ACK=1与同步请求标志SYN=1，发送自己的序列号seq=y以及客户端确认序号ack=x+1，此时服务器进入同步收到SYN_RECV状态。 - 第三次握手：客户端收到消息后发送确认标志
ACK=1，发送自己的序列号seq=x+1与服务器确认号ack=y+1，发送过后即确认链接已建立状态ESTABLISHED，服务端接收确认信息后进入链接已建立状态ESTABLISHED
解释
- 第一次握手：客户端：“兄弟，待会咱们出去玩吧，能看到我的消息吗，能就吱一声，让我知道我有发消息的能力”
- 第二次握手：服务端：“吱，走走走咱们去哪玩？我收到你的消息了，你有发消息的能力，要不你再给我回个消息，让我也确定我有发消息的能力”
- 第三次握手：客户端：“咱们先去河里摸鱼玩，然后上山摘点果子。我也收到你的消息了，你这发消息的能力也没问题，咱俩的发消息的能力都没问题，可以愉快的玩耍了”
四次挥手
client server
主动关闭 → FIN=1,seq=u → 被动关闭，接收
(终止等待1) (关闭等待)
接收 ← ACK=1,seq=v,ack=u+1 ← 发送
(终止等待2) (关闭等待)
接收 ← FIN=1,ACK=1,seq=w,ack=u+1 ← 发送
(时间等待) (最后确认)
发送 → ACK=1,seq=u+1,ack=w+1 → 接收
(时间等待 2MSL 关闭) (关闭)
来自@touchczy 的博客 https://blog.touchczy.top/#/Browser/TCP%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B
- 第一次挥手：客户端发出释放标识
FIN=1，自己的序列号seq=u，进入终止等待FIN-WAIT-1状态 - 第二次挥手：服务端收到消息后发出
ACK=1确认标志和客户端的确认号ack=u+1，自己的序列号seq=v，进入关闭等待CLOSE-WAIT状态，客户端收到消息后进入终止等待FIN-WAIT-2状态 - 第三次挥手：服务器发送释放标识
FIN=1信号，确认标志ACK=1，确认序号ack=u+1，自己的序列号seq=w，服务器进入最后确认LAST-ACK状态 - 第四次挥手：客户端收到回复后，发送确认标志
ACK=1，确认序号ack=w+1，自己的序列号seq=u+1，客户端进入时间等待TIME-WAIT状态，经过2个最长报文段寿命后，客户端CLOSE。服务器收到确认后，立刻进入CLOSE状态。
参考
TCP和UDP的区别
- TCP 是面向连接的，udp 是无连接的即发送数据前不需要先建立链接。
- TCP 提供可靠的服务。也就是说，通过 TCP 连接传送的数据，无差错，不丢失， 不重复，且按序到达;UDP 尽最大努力交付，即不保证可靠交付。 并且因为 tcp 可靠， 面向连接，不会丢失数据因此适合大数据量的交换。
- TCP 是面向字节流，UDP 面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如 IP 电话和视频会议等）。
- TCP 只能是 1 对 1 的，UDP 支持 1 对 1,1 对多。
- TCP 的首部较大为 20 字节，而 UDP 只有 8 字节。
- TCP 是面向连接的可靠性传输，而 UDP 是不可靠的。
WebSocket的实现和应用
什么是WebSocket
WebSocket 是HTML5的协议，支持持久性连接，http 协议不支持持久性连接。Http1.0 和 HTTP1.1 都不支持持久性的链接，HTTP1.1 中的 keep-alive，将多个 http 请求合并为 1 个
WebSocket 是什么样的协议，具体有什么优点？
HTTP 的生命周期通过 Request 来界定，也就是 Request 一个 Response，那么在 Http1.0 协议中，这次 Http 请求就结束了。在 Http1.1 中进行了改进，是的有一个 connection： Keep-alive，也就是说，在一个 Http 连接中，可以发送多个 Request，接收多个 Response。 但是必须记住，在 Http 中一个 Request 只能对应有一个 Response，而且这个 Response 是被动的，不能主动发起。
WebSocket 是基于 Http 协议的，或者说借用了 Http 协议来完成一部分握手，在握手阶段 与 Http 是相同的。我们来看一个 websocket 握手协议的实现，基本是 2 个属性，upgrade， connection。
# 基本请求如下：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
# 多了下面 2 个属性：告诉服务器发送的是 websocke
Upgrade:webSocket
Connection:Upgrade