手动目录
- HTTP
- HTTP是什么
- 请求报文
- 响应报文
- HTTP请求方式
- GET & POST 区别
- GET 相对 POST 的优势是什么?
- 状态码
- HTTP 三次握手、四次挥手
- Charles 的抓包原理
- HTTPS
- HTTPS的建立流程/安全建立的流程。
- UDP
- 特点
- 功能
- TCP
- 特点
- 面向连接
- 可靠传输
- 面向字节流
- 流量控制
- 拥塞控制
- 为什么要三次握手而不是2次？
- 为什么要四次挥手？
HTTP
HTTP是什么
HTTP是什么？
HTTP是超文本传输协议
是万维网和浏览器之间相互通讯的规则。
在发起请求和收到请求是有固定规则的 就是请求报文和响应报文。
请求报文
请求报文
由四部分组成:请求行、首部行、空行、请求实体。
响应报文
响应报文
由四部分组成：状态行、首部行、空行、响应实体。
HTTP请求方式
HTTP提供六种请求方式：
GET(查)、POST(改)、PUT(增)、DELETE(删)、HEAD、OPTIONS
GET & POST 区别
从2点回答才是完整的：
从语法角度看
1、get 用？@拼接参数，而post是放在请求报文的请求实体
2、get有字符串长度限制（2048个字符），而post没有限制
3、get以明文方式请求，不安全。post相对更安全一些从语义角度看
1、get：获取资源。是安全的、幂等的、可缓存的
2、post：处理资源。是非安全、非幂等、不可缓存的。
安全的：
这里的安全是指不应引起Server端的任何状态变化
幂等的：
同一个请求方法执行多次和执行一次的效果完全相同
可缓存的：
GET 请求会主动进行 Cache
GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器的限制，导致他 们在应用过程中体现出一些不同。
在响应时，GET 产生一个 TCP 数据包;POST 产生两个 TCP 数据包:
对于 GET 方式的请求，浏览器会把 Header 和实体主体一并发送出去，服务器响应 200(返回数据); 而对于 POST，浏览器先发送 Header，服务器响应 100 Continue，浏览器再发送实体主体，服务器响应 200 OK(返回数据)。
GET 相对 POST 的优势是什么?
- 1、最大的优势就是方便。GET 的 URL 可以直接手输，从而 GET 请求中的 URL 可以被存在书签里，或者 历史记录里
- 2、可以被缓存，大大减轻服务器的负担
所以大多数情况下，还是用 GET 比较好。
状态码
100~199：表示成功接收请求，要求客户端继续提交下一次请求才能完成整个处理过程。
200~299：表示成功接收请求并已完成整个处理过程。常用200
300~399：为完成请求，客户需进一步细化请求。例如：请求的资源已经移动一个新地址、常用302(意味着你请求我，我让你去找别人),307和304(我不给你这个资源，自己拿缓存)
400~499：客户端的请求有错误，常用404(意味着你请求的资源在web服务器中没有)403(服务器拒绝访问，权限不够)
500~599：服务器端出现错误，常用500
常见状态码
- 200：请求成功
- 301：请求地址发生转移，一般与响应报文中的location 产生联系
- 400：发起的请求服务器不能理解
- 403：服务器拒绝访问，权限不够
- 404：发起的请求没有响应的资源可访问。
- 505：服务器 不支持http的协议版本
一般来说 4开头的 是用户端异常 5开头通常是服务器异常。
HTTP 三次握手、四次挥手
HTTP与服务端产生链接，通过 三次握手建立连接，四次挥手断开链接。
三次握手可以理解为：我要去拜访一个朋友，
1、短信 告诉朋友 我要去拜访你可以吗 （第一次握手）
2、朋友收到短信后回复：可以来 （第二次握手）
3、我收到朋友 的回复，我 要告诉朋友我收到你的消息了 （第三次握手）。
HTTP的三次握手：
- 第一次握手：客户端：发送一个syn 数据包(syn=j) 到服务器，进入SYN_SEND状态。
- 第二次握手：服务端收到消息之后，确认客户端的 SYN（ack=j+1），然后在回复给客户端一个syn+ack。此时服务器进入 SYN_RECV 状态；
- 第三次握手：客户端收到SYN＋ACK包，然后发送给服务端一个确认消息 ACK。这个时候，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。
四次挥手：可以理解为和朋友告别
第一次挥手： 我要告诉朋友我要走了。
第二次挥手：朋友说好的，那我就走了
第三次挥手：朋友发现我有东西落下了。然后给我送出来。
第四次挥手：朋友说那我回去了。然后朋友就回去了。
HTTP的四次挥手：
- 第一次挥手：客户端向服务端发送一个终止FIN数据包。此时客户端进入终止等待的状态。
- 第二次挥手：服务端收到数据包之后，回复给客户端一个ACK。此时客户端到服务端的链接断开。
客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。所以还需要服务器也要断开。- 第三次挥手：服务端向客户端 发送一个数据包FIN+ACK。
- 第四次挥手：客户端收到消息之后向服务器回一个ACK数据包。这个时候完成服务器向客户端之间链接的断开。
HTTP的特点
2个特点：无连接、无状态
- 无连接
无连接的意思就是：我在一次发送请求之后，在满足条件下（未超时、未达到请求条数上限），可以在不重新连接的状态下直接发送http的请求报文。是一种持久连接机制。
用一张图来理解：
持久连接涉及到的头部字段
Connection:----Connection: keep_alive。客户端期许采用持久连接
time------time: 20。客户端希望在20s以内不断开连接（20s内连接是有效的，不会产生4次挥手来断开连接）
max-----max: 10。这条连接最多可以发生多少次 http连接和 响应对。既然HTTP是 无连接（持久连接），那么如何判断上一次http响应已完成？
Content-length。是一个响应头的字段。表示数据的总长度。客户端根据接受到数据的大小来判断是会否结束。
chunked。 一般 在分段传输的情况下，服务端通过多次数据下发到客户端，当最后一次chunked 为空的时候，表示这次数据传输完成。（这种情况下，响应报文的头部行中，可以不包含Content-length）。
- 无状态
Charles 的抓包原理
利用HTTP 中间人攻击 的漏洞来完成抓包。
正常来说： 客户端发送请求，是由服务器直接接受，然后响应请求，直接将数据包回传给客户端。中间人攻击，就是中间加一个中间人（代理人 ），来劫持 http的请求，然后伪装成 客户端，将数据发送给服务器，服务器返回的数据被中间人接受然后在返回给客户端。
用图来表示：
HTTPS
HTTS是安全的HTTP，安全是由SSL/TLS 这样一个插在应用层之下，传输层之上的模块来完成的。
HTTPS =HTTP +SSL/TLS
相对于HTTP，HTTPS多了一个与安全相关的模块。
SSL/TLS准确的说 是位于 应用层与传输层中间。
HTTPS的建立流程/安全建立的流程。
HTTPS 建立流程
- 1、客户端向服务端发送一个消息。
客户端会把安全协议版本号、客户端支持的加密算法列表、随机数 C 发给服务端。- 2、服务端收到消息，向客户端回消息。
服务器会将确定的的加密方式、随机数S、server证书 返回给客户端- 3、客户端 验证server
- 4、客户端组装会话密钥。
客户端会用服务器公钥来生成一个预主秘钥 。然后用预主密钥 和步骤一中的C + 步骤二中的S 通过算法得到的预主密钥- 5、客户端将预主密钥加密发送给服务端。
通过server的公钥来对前主秘钥进行非对称加密，发送给服务端。- 6、服务端通过私钥解密得到预主密钥
- 7 、服务端组装回话密钥
服务端通过预主秘钥和随机数 C、S 来组装会话秘钥。- 8、数据传输
- 1、客户端向服务端发送加密的握手消息
客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。- 2 、服务端返回一个 加密的握手消息。
服务端收到客户端发送来的密文，用服务端密钥对其进行对称解密，得到客户端发送的数据。
图解：
提及到的概念
会话密钥： 随机数S + 随机数C + 预主密钥 通过一定的机密算法得到的。
预主密钥： 客户端会用服务器公钥来生成一个预主秘钥。
- HTTPS 使用到的加密手段有哪些？
1、连接过程中，使用非对称加密。相对来说比较耗时。
2、后续数据传输 使用对称加密。
什么是非对城加密？
非对称加密就是 在加密/解密的过程中，使用不同的方式去加密/解密。
加密过程： 需要加密的数据 用 公钥进行加密。
解密过程： 需要解密的数据，用私钥进行解密。
最常接触到的：比如苹果签名的方案：
首先，先将APP内容通过摘要算法，得到摘要，再用私钥对摘要进行加密得到密文，将源文本、密文、和私钥对应的公钥-并发布。
验证方首先查看公钥是否是私钥方的，然后用公钥对密文进行解密得到摘要，将APP用同样的摘要算法得到摘要，两个摘要进行比对
对称加密：
加密/解密都借助同一个密钥进行操作
对称加密通常有 DES,IDEA,3DES 加密算法。
对称加密和非对称加密优缺点
由于私钥是保存在本地的，所以非对称加密相对与对称加密是安全的。
非对称加密比对称加密耗时(100 倍以上),所以通常要结合对称加密来使用。
UDP
TCP是在传输层，是用户数据报协议。
特点
无连接、 尽最大努力交付、面向报文。
尽最大努力交付
UDP不保证数据传输的可靠性。-
面向报文
就是既不合并，也不拆分。应用层的报文可大可小。大了不会拆分，小了也不会合并，只是简单的将应用层的数据报文作为传输层的数据报的数据部分 进行传输。
UDP传输
功能
复用、分用、差错检测
-
复用、分用
不同的应用，使用不同的端口等，在使用UDP传输的时候，都可以复用传输层的数据报，然后再由网络层进行传输。 分用则相反
复用、分用 -
差错检测
UDP差错检测
进行传输时，会将所有数据，以16位字为单元，按二进制反码计算出这些6位字的和，将和的二进制反码写入检测和位（UDP首部的末尾）。
接收方在接到收据后，用同样的方式，进行计算得到检验和，然后和传递过来的检验和进行比对。
比如在IM即时通讯聊天中，我们可以借鉴这种方式来处理。
TCP
TCP是在传输层，是传输控制协议。
特点：
面向连接、可靠传输、面向字节流、流量控制、拥塞控制。
面向连接
数据传输之前，需要建立连接（HTTP里的三次握手）
数据传输之后，需要断开连接（HTTP里的四次挥手）
可靠传输
无差错、不丢失、不重复、按序到达。
为了保证可靠传输，TCP采用的机制是：
停止等待协议：无差错、超时重传、确认丢失、确认迟到。
面向字节流传输
发送方： 发送的所有数据都在TCP的缓冲区
接收方：接收到的所有数据都在缓存区
TCP：TCP会根据自己的情况来决定每次发送多少数据。可能会将多次的数据包装成一个数据包进行发送，也可能将一次的数据，拆分成多个数据包进行发送。
这个就和UDP面向报文形成对比。
流量控制
流量控制是通过滑动窗口协议来实现的。
先看一张图
在上面面向字节流说到TCP发送方和接收方都有TCP缓冲区。向缓存区的信息由TCP按照自己组合成数据包进行发送。那么滑动窗口协议就是来控制每次发送数据的大小的。
发送方
发送方的缓冲区中，所有的字节按序号进行排列。在发送方，当上一个传输的数据接受到服务端返回的信息，开始进行下一次传输，服务端会将下一次期望接受的数据大小打包到数据里进行回传，接收方根据这个信息，动态调整发送窗口的大小。
接收方
接收方接收到数据之后，先将数据保存到缓冲区，如果数据完整，提交到应用层，如果没有完整（未按序到达），会在给客户端回传消息的时候，将下次期望接受的数据大小回传回去。
如果缓存满了。接收方会回传ACK里包含rwnd = 0的信息，这个时候，发送方会等待，过一会发送方会发一个字节为1 的探测报文，接收方会在回传发送方一个合适的期望数据大小。
拥塞控制
拥塞是为了避免网络传输过程中，被阻塞的问题，和接收方没有关系。
慢开始，拥塞避免、快恢复，快重传
-
慢开始，拥塞避免
用一张图来说明
慢开始，拥塞避免x轴表示交互次数（发送报文次数）。
y轴表示发送报文的个数 。过程解释：
1、第一次发送一个报文，如果没有产生阻塞，第二次发送2个报文，如果依然没有发生阻塞，发送 前一次的2倍个（1、2、4、8、16 直到门限制）。
2、如果达到门限值，下一次发送+1个的报文（16、17、18、19...）
3、当某一次发送的报文多次没有收到服务端的消息，我们认为产生了拥塞。
4、产生拥塞之后按/2的个数设置为新的门限值（如果发送24时产生拥塞，此时门限值为24/2 = 12）。
5、重新慢开始。从1个开始发送，然后*2 （1、2、4、8、MIN(门限值，个数)）。
6、达到新的门限值之后，按照+1个的报文数量进行发送。 快恢复，快重传
是相对于慢开始，拥塞避免而言。
对于慢开始，拥塞避免而言，在发生拥塞之后，从1开始慢重传（上面的步骤5）。
而对于快回复快重传而言，产生拥堵之后，不从1开始发送报文，而是从新的门限值开始发送报文（上面的步骤6，快恢复不经历步骤5）。
为什么要三次握手而不是2次？
我们对这图来看这个问题
假如说是2次握手：
当客户端发送请求连接报文的时候（SYN），由于在传输过程中，可能产生了阻塞等超时了。那么客户端会由于超时重传策略再次发送一个请求连接。当其中一个请求链接到达服务端，服务端给客户端回传了SYN+ACK，这个时候建立了连接，如果后面的请求连接页到达，因为TCP是无状态连接，我不知道是不是还是不是你发的， 服务器又会建立一个连接，这样实际浪费资源的。实际上客户端只是想建立一次连接。
如果是3次握手，那么
第二次连接的时候，客户端收到SYN+ACK之后，不在向服务器发送ACK，这样第二次连接就不会建立。
为什么要四次挥手？
服务端与客户端之间建立的全双工，意思就是说，在这个通道里，2边都可以主动传输数据。这个时候需要2边都断开连接。
更多关于HTTP握手/挥手的面试题 参考这篇文章