知识梳理系列之四——网络协议(TCP/IP、Http/Https)

知识梳理系列之四——网络协议TCP/IP、Http/Https

• 网络分层模型若干问题
• OSI七层模型和TCP/IP四层模型
• TCP/IP的握手与挥手
• 三次握手：
• 为什么要三次握手？
• 四次挥手
• 为什么要四次挥手？
• Http协议与Https协议

网络分层模型若干问题

本文是对基本知识的个人总结，旨在面试遇到时，能逻辑条理清晰。不是全面知识学习文本。

OSI七层模型和TCP/IP四层模型

1. OSI七层网络模型和TCP/IP四层模型图示
   
   TCP/IP是一组协议族，包含很多协议，常见的比如UDP、HTTP、S-HTTP(HTTPS)、SSL/TLS、FTP、SMTP、POP3、DHCP、SOCKS等等，其中HTTP/FTP/SMTP/POP3/SOCKS等属于应用层协议。TCP/UDP协议是网络层协议、IP协议是传输层协议。
   Socket网络套接字是一个使用TCP/IP的接口，方便访问和使用这些协议，本身不是协议。

2. 其中HTTPS协议就是HTTP + SSL/TLS
   SSL是Secure Sockets Layer的缩写，由Netscap发布，经IEEE标准化为TLS，目前主流的是TLS 1.1、TLS 1.2版本。

3. TCP与UDP的区别：
   a. TCP保证数据在网络中的正确性、顺序性，而UDP不保证；
   b. UDP由于不保证上述性质，省去了校验正确和顺序收发，在传输上更快速。

TCP/IP的握手与挥手

三次握手：

如下图所示：

说明：三次握手步骤：

• 客户端服务端分别打开传输控制块TCB，服务端进入LISTEN状态，客服端发起请求，并带数据SYN=1,seq=x（seq是一个序列数，序列数一般是发送数据的长度,握手时序列数都是+1不带其他数据），发送后客户端进入SYN_SEND状态；
• 服务端收到请求，并向客户端回复数据：ACK=1,SYN=1,ack=x+1,seq=y（表示收到了客户端的SYN=1,回复确认ACK=1,并且客户端的序列数+1,自己的数据序列数y），服务端进入SYN_RCVD状态；
• 客户端收到服务端的确认，并发送建立连接确认数据：ACK=1,ack=y+1,seq=x+1（表示客户端收到了服务端的确认，并回复服务器建立连接），客户端进入ESTABLISH，服务端收到客户端的确认数据后也进入ESTABLISH状态，此时连接建立。

为什么要三次握手？

可以看到完成第二次握手时，相当于服务端收到了客户端的请求，并且客户端也知晓的状态，为什么还需要进行第三次握手呢？
答案：主要是为了避免失效请求重复连接
一种常见场景：
一次客户端请求发出后，网络环境不畅，请求停留在网络中，客户端在长时间没有收到回复，尝试重新请求，此时网络畅通，并成功建立连接，完成数据交换并关闭连接，此时停留在网络中的上次请求又到达了服务器。
此时，如果只有两次握手将再次建立连接，这是不符合预期的！并且造成资源浪费。
那么是三次握手时，服务端收到失效的请求后，向客户端发送确认数据，但是客户端发现自己并没有请求，于是不做回复，此时，避免了失效请求导致重复连接！！

---

四次挥手

说明：四次挥手步骤：

• 客户端发起断开连接请求，FIN=1,seq=u，客户端进入FIN-WAIT-1状态；
• 服务端收到此请求后，回复客户端：ACK=1,ack=u+1,seq=v(此时没有回复FIN=1，因为服务端有可能有数据还没有发送完，只告知客户端我收到了你的FIN请求，我还有数据没发完)，此时服务端进入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状态，服务端收到后就CLOSE了，客户端在TIME_WAIT超时后进入CLOSE。

为什么要四次挥手？

分解成两个问题：

1. 为什么服务端回复客户端的FIN请求，有两次一次ACK，一次FIN/ACK?
   因为服务端收到请求后，有可能还有客户端请求的数据没有发送完成，所以第一次ACK是告知客户端我收到你的FIN请求了，第二次FIN/ACK是告知客户端你要的数据我都发出去了。服务端等客户端确认知晓其已经发送完了数据，如果期间超时没有收到确认，服务端还会重发。
2. 为什么客户端CLOSE之前有TIME_WAIT?
   因为客户端在收到FIN/ACK后需要给服务端ACK，告知我收到了，如果客户端发完ACK，立即CLOSE，有可能服务端未收到ACK而关闭不了，TIME_WAIT保持客户端未关闭，是的服务端没有收到客户端的ACK时还可以再重发FIN/ACK；
   另外一个作用是清除网络中的无效报文。

Http协议与Https协议

HTTP是一种超文本传输协议，通常使用统一资源定位符URL来获取网络资源。

1. 请求报文格式
    
   请求头： 请求方法(如GET/POST)     资源路径或参数     HTTP协议版本
   请求行： 就是Request对象里的一系列配置
         比如：Host、User-Agent、Content-Type、Content-Length、Content-Encoding、
         Content-Language、Accept-Type、Accept-Language、Connection(Keep-Alive)等等；
   空行
   请求体：(POST有/GET无)
    

2. 响应报文格式
    
   状态行： 协议版本     状态码     状态短语
   响应头： Date 时间日期
         charset 、Content-Type
         Content-Length等等
   空行
   响应正文：比如 json 字符串等
    
   状态码：

   状态码	含义
   1xx	继续执行
   2xx	成功
   3xx	重定向
   4xx	客户端错误
   5xx	服务端问题

    

3. 与Https的区别
   区别在于在表示层使用了SSL/TLS，来进行身份校验(服务器CA证书)，并使用密文传输请求数据。
   http使用的是明文传输。
   https会牺牲一部分速度，但总体影响不大；
   常用的加密方式非对称加密、对称加密；

4. 附：有趣的加密原理(离散对数方案)
   非对称加密的离散对数方案：
   已知公钥：p、alpha
   ALICE要和BOB加密通信，不希望被EVE窃密；
   希望有一种加密方式，用已知的加密算法，ALICE用私钥a加密数据Data发送给BOB，BOB接收到密文用自己的私钥b就能解密；

   EVE只能从网络中拿到两者加密后的数据，在一定时间内无法穷举出密码。

   ALICE： 将计算：y = alpha^a mod p 将计算结果发送到网络中；BOB和EVE都可以收到

   BOB：将计算：z = alpha^b mod p 将计算结果发送到网络中；ALICE和EVE都可以收到

   ALICE：将收到的z 进行计算：z^a mod p

   BOB：将收到的y 进行计算：y^b mod p

   此时发现ALICE和BOB算出了一致的结果，这样就完成了加密通信的建立，确保两个身份合法的人连接到了一起，而EVE由于算不出一致的结果而无法窃密。

其中mod就是取余计算。