1、三次握手
TCP建立连接
必须进行三次握手：若A要与B进行连接，则必须
- 第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认。即A发送信息给B
- 第二次握手：服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认。即B收到连接信息后向A返回确认信息
- 第三次握手：客户端收到服务器的（SYN+ACK）报文段，并向服务器发送ACK报文段。即A收到确认信息后再次向B返回确认连接信息
此时，A告诉自己上层连接建立；B收到连接信息后告诉上层连接建立。
这样就完成TCP三次握手 = 一条TCP连接建立完成 = 可以开始发送数据
- 三次握手期间任何一次未收到对面回复都要重发。
- 最后一个确认报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态。
为什么TCP建立连接需要三次握手？
答：防止服务器端因为接收了早已失效的连接请求报文从而一直等待客户端请求，从而浪费资源
- “已失效的连接请求报文段”的产生在这样一种情况下：Client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。
- 这是一个早已失效的报文段。但Server收到此失效的连接请求报文段后，就误认为是Client再次发出的一个新的连接请求。
- 于是就向Client发出确认报文段，同意建立连接。
- 假设不采用“三次握手”：只要Server发出确认，新的连接就建立了。
- 由于现在Client并没有发出建立连接的请求，因此不会向Server发送数据。
- 但Server却以为新的运输连接已经建立，并一直等待Client发来数据。>- 这样，Server的资源就白白浪费掉了。
以上答案只是表象，没有说到本质上去
那么本质是 因为tcp是全双工，为保证传输的可靠性，需要给每次传输的数据段添加序号，那么初始的序列号就是tcp三次握手真正的意义所在，而为了确保交换双方的初始序号，最少需要三次才行
采用“三次握手”的办法可以防止上述现象发生：
-
Client不会向Server的确认发出确认
-
Server由于收不到确认，就知道Client并没有要求建立连接
-
所以Server不会等待Client发送数据，资源就没有被浪费
2、四次挥手
TCP释放连接
TCP释放连接需要四次挥手过程，现在假设A主动释放连接：（数据传输结束后，通信的双方都可释放连接）
-
第一次挥手：A发送释放信息到B；（发出去之后，A->B发送数据这条路径就断了）
-
第二次挥手：B收到A的释放信息之后，回复确认释放的信息：我同意你的释放连接请求
-
第三次挥手：B发送“请求释放连接“信息给A
-
第四次挥手：A收到B发送的信息后向B发送确认释放信息：我同意你的释放连接请求
B收到确认信息后就会正式关闭连接； A等待2MSL后依然没有收到回复，则证明B端已正常关闭，于是A关闭连接
为什么TCP释放连接需要四次挥手？
为了保证双方都能通知对方“需要释放连接”，即在释放连接后都无法接收或发送消息给对方
-
需要明确的是：TCP是全双工模式，这意味着是双向都可以发送、接收的
-
释放连接的定义是：双方都无法接收或发送消息给对方，是双向的
-
当主机1发出“释放连接请求”（FIN报文段）时，只是表示主机1已经没有数据要发送 / 数据已经全部发送完毕；但是，这个时候主机1还是可以接受来自主机2的数据。
-
当主机2返回“确认释放连接”信息（ACK报文段）时，表示它已经知道主机1没有数据发送了，但此时主机2还是可以发送数据给主机1
-
当主机2也发送了FIN报文段时，即告诉主机1我也没有数据要发送了
此时，主机1和2已经无法进行通信：主机1无法发送数据给主机2，主机2也无法发送数据给主机1，此时，TCP的连接才算释放
为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
3、一次完整的HTTP请求
-
首先进行DNS域名解析（本地浏览器缓存、操作系统缓存或者DNS服务器）
-
三次握手建立 TCP 连接
在HTTP工作开始之前，客户端首先要通过网络与服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能进行高层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。
-
客户端向服务器发送请求命令 Get /www.xx.com/ http/1.1
-
客户端发送请求头信息
客户端发送其请求命令之后，还要以头信息的形式向服务器发送一些别的信息，之后客户端发送了一空白行来通知服务器，它已经结束了该头信息的发送。
-
服务器应答 Http/1.1 200 OK
-
服务器返回响应头信息
正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
-
服务器向客户端发送数据
服务器向客户端发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
-
服务器关闭 TCP 连接
一般情况下，一旦服务器向客户端发送了数据，它就要关闭TCP连接，然后如果客户端或者服务器在其头信息加入了这行代码：
Connection:keep-alive
TCP连接在发送后将仍然保持打开状态，于是，客户端可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。
4、HTTP缓存机制及原理
HTTP缓存有多种规则，根据是否需要重新向服务器发起请求来分类，将其分为两大类(强制缓存，对比缓存)
两类缓存规则不同，强制缓存如果生效，不需要再和服务器发生交互，而对比缓存不管是否生效，都需要与服务端发生交互。
两类缓存规则可以同时存在，强制缓存优先级高于对比缓存，也就是说，当执行强制缓存的规则时，如果缓存生效，直接使用缓存，不再执行对比缓存规则。
强制缓存
对于强制缓存来说，响应header中会有两个字段来标明失效规则（Expires/Cache-Control）
Expires
Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。
不过Expires 是HTTP 1.0的东西，现在默认浏览器均默认使用HTTP 1.1，所以它的作用基本忽略。
另一个问题是，到期时间是由服务端生成的，但是客户端时间可能跟服务端时间有误差，这就会导致缓存命中的误差。
所以HTTP 1.1 的版本，使用Cache-Control替代。
Cache-Control
Cache-Control 是最重要的规则。常见的取值有private、public、no-cache、max-age，no-store，默认为private。
private: 客户端可以缓存
public: 客户端和代理服务器都可缓存（前端的同学，可以认为public和private是一样的）
max-age=xxx: 缓存的内容将在 xxx 秒后失效
no-cache: 需要使用对比缓存来验证缓存数据（后面介绍）
no-store: 所有内容都不会缓存，强制缓存，对比缓存都不会触发（对于前端开发来说，缓存越多越好，so…基本上和它说886）
对比缓存
对比缓存，顾名思义，需要进行比较判断是否可以使用缓存。
浏览器第一次请求数据时，服务器会将缓存标识与数据一起返回给客户端，客户端将二者备份至缓存数据库中。
再次请求数据时，客户端将备份的缓存标识发送给服务器，服务器根据缓存标识进行判断，判断成功后，返回304状态码，通知客户端比较成功，可以使用缓存数据。
对于对比缓存来说，缓存标识的传递是我们着重需要理解的，它在请求header和响应header间进行传递，
一共分为两种标识传递：
Last-Modified / If-Modified-Since
Last-Modified：
服务器在响应请求时，告诉浏览器资源的最后修改时间。
If-Modified-Since：
再次请求服务器时，通过此字段通知服务器上次请求时，服务器返回的资源最后修改时间。
服务器收到请求后发现有头If-Modified-Since 则与被请求资源的最后修改时间进行比对。
若资源的最后修改时间大于If-Modified-Since，说明资源又被改动过，则响应整片资源内容，返回状态码200；
若资源的最后修改时间小于或等于If-Modified-Since，说明资源无新修改，则响应HTTP 304，告知浏览器继续使用所保存的cache。
Etag / If-None-Match（优先级高于Last-Modified / If-Modified-Since）
Etag：
服务器响应请求时，告诉浏览器当前资源在服务器的唯一标识（生成规则由服务器决定）。
If-None-Match：
再次请求服务器时，通过此字段通知服务器客户段缓存数据的唯一标识。
服务器收到请求后发现有头If-None-Match 则与被请求资源的唯一标识进行比对，
不同，说明资源又被改动过，则响应整片资源内容，返回状态码200；
相同，说明资源无新修改，则响应HTTP 304，告知浏览器继续使用所保存的cache。
对于强制缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
对于比较缓存，将缓存信息中的Etag和Last-Modified通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。
5、http/https、https单向认证和双向认证
Http
HyperText Transfer Protocol，超文本传输协议，是互联网上使用最广泛的一种协议，所有WWW文件必须遵循的标准。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。
使用TCP端口为：80
Https
Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。
使用TCP端口默认为443
SSL协议加密方式
SSL协议即用到了对称加密也用到了非对称加密(公钥加密)，在建立传输链路时，SSL首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL对传输内容使用对称加密。
对称加密
速度高，可加密内容较大，用来加密会话过程中的消息
公钥加密
加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥
单向认证
Https在建立Socket连接之前，需要进行握手，具体过程如下：
- 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
- 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
- 客户端使用服务端返回的信息验证服务器的合法性，包括：
- 证书是否过期
- 发型服务器证书的CA是否可靠
- 返回的公钥是否能正确解开返回证书中的数字签名
- 服务器证书上的域名是否和服务器的实际域名相匹配
- 验证通过后，将继续进行通信，否则，终止通信
- 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
- 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
- 服务器将选择好的加密方案通过明文方式返回给客户端
- 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器
- 服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
双向认证
双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：
- 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
- 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
- 客户端使用服务端返回的信息验证服务器的合法性，包括：
- 证书是否过期
- 发型服务器证书的CA是否可靠
- 返回的公钥是否能正确解开返回证书中的数字签名
- 服务器证书上的域名是否和服务器的实际域名相匹配
- 验证通过后，将继续进行通信，否则，终止通信
- 服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端
- 服务端验证客户端的证书，通过验证后，会获得客户端的公钥
- 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
- 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
- 将加密方案通过使用之前获取到的公钥进行加密，返回给客户端
- 客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端
- 服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥。
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。