内容包括：
- TCP协议
- HTTPS握手过程
- HTTP与Socket的区别
一、TCP网络协议
1.1 Socket通信过程
socket是"打开—读/写—关闭"模式的实现，以使用TCP协议通讯的socket为例，其交互流程大概如下：
socket通信过程
（1）服务器根据地址类型（ipv4,ipv6）、socket类型、协议创建socket
服务器为socket绑定ip地址和端口号
服务器socket监听端口号请求，随时准备接收
（2）客户端发来的连接，这时候服务器的socket并没有被打开
客户端创建socket
客户端打开socket，根据服务器ip地址和端口号试图连接服务器socket
（3）服务器socket接收到客户端socket请求，被动打开，开始接收客户端请求，直到客户端返回连接信息。这时候socket进入阻塞状态，所谓阻塞即accept()方法一直到客户端返回连接信息后才返回，开始接收下一个客户端谅解请求
（4）客户端连接成功，向服务器发送连接状态信息
（5）服务器accept方法返回，连接成功
（6）客户端向socket写入信息
（7）服务器读取信息
（8）客户端关闭
（9）服务器端关闭
1.2 TCP三次握手
TCP协议通过三次握手建立一个可靠的连接。
TCP三次握手
第一次握手：客户端尝试连接服务器，向服务器发送syn包（同步序列编号Synchronize Sequence Numbers），syn=j，客户端进入SYN_SEND状态等待服务器确认第二次握手：服务器接收客户端syn包并确认（ack=j+1），同时向客户端发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手
解释
在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。
书中例子：“已失效的连接请求报文段”的产生在这样一个情况下：client发出的第一个连接请求报文并没有丢失，而是在某个网站结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，统一建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确定，也不会向server发送数据。而server确以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了，采用“三次握手”的办法可以防止上述现象发生。
1.3 TCP四次挥手
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
TCP四次挥手
解释
原因是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。
二、HTTPS网络协议
2.1 握手与密钥协商过程
基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程
HTTPS握手过程
(1).client_hello
客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
- 支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本; * 客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);
- 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;
- 随机数 random_C，用于后续的密钥的生成;
- 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
(2).server_hello+server_certificate+sever_hello_done
- server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;
- server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;
- server_hello_done，通知客户端 server_hello 信息发送结束;
(3).证书校验
客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：
- [证书链]的可信性 trusted certificate path，方法如前文所述;
- 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
- 有效期 expiry date，证书是否在有效时间范围;
- 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
- client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
- 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥; enc_key=Fuc(random_C, random_S, Pre-Master)
- change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
- encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
(5).change_cipher_spec+encrypted_handshake_message
- 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
- 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
- change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
- encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
(6).握手结束
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
(7).加密通信
开始使用协商密钥与算法进行加密通信。
2.2 会话缓存握手过程
为了加快建立握手的速度，减少协议带来的性能降低和资源消耗(具体分析在后文)，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。
session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多;
session ticket 需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。
二者都存在的情况下，(nginx 实现)优先使用 session_ticket。
握手过程如下图:
会话握手过程
注意：虽然握手过程有1.5个来回，但是最后客户端向服务器发送的第一条应用数据不需要等待服务器返回的信息，因此握手延时是1*RTT。
(1).会话标识 session ID
- (a) 如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中;
- (b) 如果客户端再次需要和该服务器建立连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器;
- (c) 服务器根据收到的 session ID 检索缓存记录，如果没有检索到货缓存过期，则按照正常的握手过程进行;
- (d) 如果检索到对应的缓存记录，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用类似，encrypted_handshake_message 是到当前的通信参数与 master_secret的hash 值;
- (f) 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
- (g) 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
(2).会话记录 session ticket
- (a) 如果客户端和服务器之间曾经建立了连接，服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息，客户端保存;
- (b) 如果客户端再次需要和该服务器建立连接，则在 client_hello 中扩展字段 session_ticket 中携带加密信息，一起发送给服务器;
- (c) 服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握手过程进行;
- (d) 如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用与 session ID 中类似;
- (f)如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
- (g) 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
三、HTTP与Socket的区别
要弄明白 http 和 socket 首先要熟悉网络七层：
OSI七层协议
HTTP 协议:超文本传输协议，对应于应用层，用于如何封装数据.
TCP/UDP 协议:传输控制协议，对应于传输层，主要解决数据在网络中的传输。
IP 协议:对应于网络层，同样解决数据在网络中的传输。
传输数据的时候只使用 TCP/IP 协议(传输层)，如果没有应用层来识别数据内容，传输后的协议都是无用的。而我们平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口(API)。通过Socket，我们才能使用TCP/IP协议。
3.1 HTTP协议
http为短连接：客户端发送请求都需要服务器端回送响应，请求结束后，主动释放连接，因此为短连接。通常的做法是，不需要任何数据，也要保持每隔一段时间向服务器发送“保持连接”的请求。这样可以保证客户端在服务器端是“上线”状态。
HTTP连接使用的是“请求-响应”方式，不仅在请求时建立连接，而且客户端向服务器端请求后，服务器才返回数据。
3.2 Socket连接
要想明白Socket，必须要理解TCP连接：
TCP三次握手：握手过程中并不传输数据，在握手后服务器才与客户端开始传输数据。理想状态下，TCP连接一旦建立，只要通讯双方中的任何一方不主动断开连接，TCP连接会一直保持下去。在实际应用中，由于网络节点过多，在传输过程中，会被节点断开连接，因此要通过轮询高速网络，使该节点处于活跃状态。
Socket是对TCP/IP协议的封装，Socket只是个接口不是协议，通过Socket我们才能使用TCP/IP协议。创建Socket连接的时候，可以指定传输层协议，可以是TCP或者UDP。当用TCP连接，该Socket就是个TCP连接。
很多情况下，都是需要服务器端向客户端主动推送数据，保持客户端与服务器端的实时同步。
（1）若双方是Socket连接，可以由服务器直接向客户端发送数据。
（2）若双方是HTTP连接，则服务器需要等客户端发送请求后，才能将数据回传给客户端。因此，客户端需要定时向服务器端发送请求，不仅可以保持在线，同时也询问服务器是否有新数据，如果有就将数据传给客户端。
网友评论