网络协议总结(TCP,UDP,HTTP,HTTPS)

TCP/IP总结

一. 网络模型

1. OSI七层

2. TCP/IP五层

OSI是参考标准
TCP/IP是事实标准

二. TCP/UDP

1. TCP头部结构

TCP端口号
TCP的连接是需要四个要素确定唯一一个连接：
（源IP，源端口号）+ （目的IP，目的端口号）
所以TCP首部预留了两个16位作为端口号的存储，而IP地址由上一层IP协议负责传递
源端口号和目的端口各占16位两个字节，也就是端口的范围是2^16=65535
另外1024以下是系统保留的，从1024-65535是用户使用的端口范围

TCP的序号和确认号
32位序号 seq：Sequence number 缩写seq ，TCP通信过程中某一个传输方向上的字节流的每个字节的序号，通过这个来确认发送的数据有序，比如现在序列号为1000，发送了1000，下一个序列号就是2000。
32位确认号 ack：Acknowledge number 缩写ack，TCP对上一次seq序号做出的确认号，用来响应TCP报文段，给收到的TCP报文段的序号seq加1。

TCP的标志位
每个TCP段都有一个目的，这是借助于TCP标志位选项来确定的，允许发送方或接收方指定哪些标志应该被使用，以便段被另一端正确处理。
用的最广泛的标志是 SYN，ACK 和 FIN，用于建立连接，确认成功的段传输，最后终止连接。

窗口： 窗口大小是接收端用来控制发送的滑动窗口大小

2. 三次握手

第一次握手
客户端将TCP报文标志位SYN设置为1，随机产生一个序号值seq=J ，保存在TCP首部的序列号字段里，发送给服务端，客户端进入SYN_SENT状态。
第二次握手
服务端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务端将TCP保温标志位SYN和ACK都设置为1，ack=J+1,随机产生一个序号值seq=K,并将该数据包发送给客户端确认连接请求，服务端进入SYN_RCVD状态
第三次握手
客户端收到确认后，检查ack是否为J+1,ACK是否为1，如果正确则发送TCP报文，并设置ACK为1，ack=K+1 客户端进入ESTABLISHED状态，服务端检查ack是否为K+1,ACK是否为1，如果正确则连接成功，服务端进入ESTABLISHED状态完成三次握手。
注意：

• 小写的ack代表的是头部确认号 Acknowledge number，缩写ack,是对上一个包的序号进行确认的号，ack=seq+1
• 大写的ACK，则是TCP首部的标志位，用于标志的TCP包是否对上一个包进行了确认操作。

为什么需要三次握手？
本质就是为了增加相互信任，不让服务端浪费连接资源。
假设是两次握手完成连接
client发出了一个连接请求报文，因网络原因滞留在某一个网络节点上，client会超时重发又重新发送一个请求与server建立连接并进行传输数据，随后关闭连接。这时候之前的哪一个请求到达server,server 肯定是要响应的，基于是二次握手，server一响应就代表了连接建立，可是客户端已经完成了自己的数据传输，白白浪费了server的连接资源。
实际场景例子：
订餐
工作了一天累了，晚上准备搓一顿。
我发了一个短信给商家： 我要订一个餐位。（一次握手）
商家接受到短信回了一个： 姓名，几点 （二次握手）
我回了个： 老八，七点。 （三次握手）
这就算完成了订餐操作，我确定了商家给我留位置了，商家也确定了我确实要来并且几点来，叫什么。

3. 四次挥手

TCP是全双工通信，所以挥手请求可以是client端，也可以是Server端发起的，假设是Client端发起：
第一次挥手
Client端发起挥手请求，向Server端发送标志位是FIN报文段，设置序列号seq,此时客户端进入FIN_WAIT_1状态，表示客户端没有数据要发送给Server端了
第二次挥手
Server端收到了FIN报文，向client返回一个标志位是ACK的报文段，ack设为seq+1,Client端进入FIN_WAIT_2状态，Server端告诉Client端，我确认了并同意了你的关闭请求。服务端进入Close_wait 状态
第三次挥手
当server端也已经将数据都发送完了，没有数据给客户端了，server向client发送标志位是FIN的TCP报文，请求关闭连接。服务端进入LAST_ACK状态
第四次挥手
client收到server端发送的FIN报文，向server端发送标志位是ACK的报文端，然后client进入TIME_WAIT状态。server端收到ACK报文段以后，就关闭连接，同时，client等待2MSL的时间后依然没有收到恢复，证明server端已正常关闭，client也关闭连接。

为什么要等待2MSL
MSL: 报文段最大生成时间，它是任务报文段被丢弃前在网络内的最长时间
有以下两个原因

• 一， 保证TCP协议的全双工连接能够可靠关闭，由于IP协议的不可靠性或者其他网络原因，导致了server没有收到client的ACK报文，那么server就会在超时后重发FIN，如果此时client连接已经关闭，那么重发的FIN找不到对应的连接，从而导致连接错乱，所以，Client端发送完最后的ACK后不能直接进入CLOSED状态，而要报纸TIME_WAIT，当再次收到FIN时，能够保证对方收到ACK，确保正常关闭。
• 二，保证这次连接的重复数据端从网络中消失： 如果client发送最后的ACK直接进入CLOSED状态，然后又再向server发起一个连接，这时候不能保证新连接的与刚关闭的连接的端口号是不同的，也就是新连接和老连接的端口号可能一样了，那么就出现了问题，如果前一次的连接某些数据滞留再网络中，这些延迟数据在建立新连接后到达client，由于新老连接的端口号是一样的，TCP协议就认为这些延迟数据是属于新连接的，新连接就会接受到脏数据，导致数据包混乱。所以TCP连接需要在TIME_WAIT状态等待两倍MSL，确保本次连接的所有数据再网络中消失。

4. 流量控制

流量控制：
是作用域接收者的，它是控制发送者的发送速度，从而使得接收者来得及接受，防止丢包的。
TCP利用滑动窗口实现流量控制的机制，而滑动窗口大小是通过TCP首部的窗口大小来通知对方。
在TCP协议的头部信息中，有一个16位字段的窗口大小，窗口大小的内容实际上是接受端接受数据缓冲区的剩余大小。这个数字越大，整明接受端接受缓冲区的剩余空间越大，网络的吞吐量越大。不过，当接受端这个接收缓冲区面临数据溢出时，窗口大小就会随之设置成一个更小值，告诉发送端控制发送的数据量。
流量控制的具体操作就是：接受端会在确认应答发送ACK报文时，将自己的即使窗口大小rwnd（receiver window）填入，跟随ACK报文一起发送，发送方根据ACK报文里的窗口大小进而改变自己的发送速度。

4.1 滑动窗口

TCP是以段为单位进行数据包的发送的
在TCP三次握手的建立连接阶段，client和server互相交换MSS(最大消息长度：Max Segment Size),在TCP首部写入MSS选项，告诉对方自己的接口能适应的MSS的大小，会在两者之间选择一个最小值投入使用。
但是这样会有一个问题，基于TCP的确认应答机制如下图所示：

如上图所示，如果数据包的往返时间（RTT）较长，那么通信性能就会很低。
为解决这个问题,TCP引入窗口这个概念。确认应答不是以每个分段来确认，而是以更大的单位进行确认，转发时间将会大幅缩短。也就说，发送端主机，在发送了一个段以后不必要一致等待确认应答，而是继续发送。

假设窗口大小为4000字节，主机A可以一口气发送4000字节的序列号发送完毕。这个跟前面每个段接受ACK后才继续发送一个新的段相比，效率嗷嗷叫，即使RTT边长也不会影响网络吞吐量。窗口大小就是指无需等待确认应答ACK而继续发送数据的最大值。这种窗口机制实现了使用大量缓冲区，通过对多个段同时进行确认应答的功能。

4.1.1 滑动窗口控制与重发控制

在使用了窗口控制中，如果出现了丢包怎么办？昨两种分析：

• 某个报文丢失：
  如果接受端主机接受到一个自己应该接受的序列号之外的数据包时，它会一直对当前接受到的数据吧返回确认应答包。
  
  如上图所示，主机A的1001-2000序列号的报文丢失，它会一致收到来自主机B的一个
  1001的ACK。当主机A连续收到这个1001的确认应答ACK3次后，就会认为数据丢失，需要重发。这种机制比 超时重发 更加高效，也被称之为高速重发控制。
• 确认应答ACK未能正确返回 在这种情况下，数据时已经被对端主机成功接受的了，是不需要进行重新发送的。然后，如果在没有使用窗口控制的前提下，没有收到确认应答包的数据包都会被重发，但是在使用了窗口控制后，某些应答包即使丢了也无需重发，提高了传输效率。
  如图所示： 一个段大小为1000字节，一个窗口大小为6000个字节的情况，主机A连续发送了6000序列号的数据，中间的主机B对1001的ACK丢失了，但是后面的2001的ACK正常返回，说明前2000的序列号数据都能够正常读取，即使1001的ACK丢失也不需要进行数据重发！所以在窗口控制下，前面的ACK丢失，也能通过下一个ACK进行确认，提高了不少效率。

小结

TCP协议在实现传输可靠性上面做了很多

• 通过序列号和确认应答信号确保了数据不会重复发送和重复接受。
• 通过超时重发控制保证即使数据包在传输过程中丢失，也能重发保证数据完整
• 通过三次握手，四次回收和关闭连接的连接管理保证了端对端的通信可靠性
• TCP还使用了滑动窗口控制提高了数据传输效率

5. 拥塞控制

什么是拥塞？

计算机网络中的资源是有限的。某段时间内网络中对资源的需求超过了网络中的可用部分，而导致网络性能下降的情况就是拥塞。简单来说就是发送数据包太多网络中的设备处理不过来，导致网络性能下降。
TCP为什么要进行拥塞控制？
网络中的路由器会有一个数据包处理队列，当路由器收到的数据包太多而一下子处理不过来时，就会导致数据包处理队列过长。此时，路由器就会无条件丢失新接受到的数据封包。这就会导致上层的TCP协议以为数据包在网络中丢失，进而重传这些数据包，而路由器又会丢弃这些重传的数据包，如此以往，就会导致网络性能急剧下降，引起网络瘫痪。因此，TCP需要控制数据包发送的数量来避免网络性能的下降。

拥塞控制原理
有了TCP的滑动窗口控制，收发主机之间不在以一个段为单位，而是以一个窗口为单位发送确认应答信号，所以发送主机能够连续发送大量数据包。然后，如果在通信刚开始的时候就发送大量数据包，也有可能导致网络瘫痪。
在拥塞控制中，发送放维持一个叫做拥塞窗口cwnd(congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地变化。发送窗口取拥塞窗口和接受端窗口的最小值，避免发送接受端窗口还大的数据。
拥塞控制使用了两个重要的算法： 慢启动算法，拥塞避免算法

5. 1 慢启动算法

慢启动算法的思路是，不要一开始就发送大量数据，先试探一下网络的拥塞程度，也就是说由小到大的逐渐增加拥塞窗口的大小。慢算法中，每个传输轮次后将cwnd加倍。举个例子：一开始发送方设置cwnd=1 ，然后每经过一个传输轮次，cwnd都加倍，比如1，2，4，8 指数增长 所以这里的慢启动，不是指拥塞窗口增长慢，而是相对于一开始就上来传输大窗口数据显得慢。
当然，cwnd的大小不可能一直以这种指数的方式增长下去，要不然很快就会增长到引起网络崩溃的程度了。所以，经过一定时间或条件，我们就要换成拥塞避免算法来发送数据。

5. 2 拥塞避免算法

拥塞避免算法也是逐渐的增大cwnd的大小，只是采用线程增长，而不是慢启动算法的指数增长。具体来说就是每个传输轮次后将cwnd的大小+1（加法增长），如果发现出现网络拥塞的话就按照上面的方法重新设置ssthresh的大小（乘法减小，原来的二分之一）并从cwnd=1开始重新执行满开始算法。

慢启动算法和拥塞避免算法结合：
在拥塞控制中，慢启动算法和拥塞避免算法如何配合使用呢？
如上面所说，慢启动算法下的cwnd大小是指数增长，所以不能任cwnd任意增长，所以我们引入了一个慢启动门限(ssthresh)的阈值来控制cwnd的增长。

• cwnd < ssthresh ,使用慢启动算法
• cwnd>ssthresh ，使用拥塞避免算法
• cwnd-ssthresh , 满开始与拥塞避免算法随机

那么这个ssthresh是如何设置的呢？
TCP/IP中规定无论是在满开始阶段还是在拥塞避免阶段，只要发生网络中出现拥塞（没有按时收到确认），就要把ssthresh设置为此时发送窗口的一半大小（不能小于2）

大致流程：

• 一开始把ssthresh初始值设置16，开始慢启动增加拥塞窗口cwnd,直到cwnd=16,开始使用拥塞避免算法
• 使用用酸避免算法线性增加cwnd,直到cwnd=24，这是出现网络拥塞(ACK确认信号没有及时到达)，把ssthresh设置为原来的一半（拥塞窗口的一半）也就是ssthresh=12,然后执行拥塞避免算法进行加法增大，直到遇到网络拥塞，把ssthresh调成拥塞窗口的一半。
• 如此反复动态计算cwnd，达到拥塞控制的目的。

参考文章：
https://mp.weixin.qq.com/s/IYopLBVowY8eWDZ0XOQ8IQ
https://juejin.cn/post/6844904070289981448
https://juejin.cn/post/6844904072181465095
https://juejin.cn/post/6844904073611722760

三. HTTP与HTTPS

3.1 HTTP

3.1.1 特点

超文本传输协议
无状态：每一次请求都要连接一次，请求结束就会断掉，不保持连接，每一次请求都是独立的。
灵活：通过http协议头部的content-type标记，可以传输任意数据类型的数据对象（文本，图片，视频等），非常灵活
简单快速：发送请求访问某个资源，只需要传送请求方法和URL就可以了，使用简单。
缺点：
无状态：请求不会记录任务连接信息，没有记忆，就无法区分多个请求发起者身份是不是同一个客户端。
明文传输： 报文(header)使用的是明文，直接将信息暴露给了外界。
队头阻塞： 开启长连接时，只建立一个TCP连接，同一个时刻只能处理一个请求，那么当请求耗时过长时，其他请求就只能阻塞状态。

3.1.2 http报文组成部分

请求报文： 请求行，请求头，空行，请求体
响应报文： 状态行，响应头，空行，响应体

3.1.3 http状态码

1xx: 表示目前是协议处理的中间状态，还需要后续操作。
2xx: 表示成功状态。
3xx: 重定向状态，资源位置发生变动，需要重新请求。
4xx: 请求报文有误。
5xx: 服务器端发生错误。

3.1.3 http1.0 vs http1.1

长连接
HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的小号和延迟，在HTTP1.1默认开启长连接keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器要建立一个长连接
HOST域
在HTTP1.0中认位每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名(hostname),HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且他们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有Host域会报告一个错误(400 Bad Request)

3.1.4 队头阻塞

因为HTTP规定报文必须一发一收（请求-应答模式），这就形成了一个先进先出的串行队列。队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求被最先处理。
如果队首的请求因为处理的太慢当误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本。

3.1.4.1 并发连接

并发连接是同时对一个域名发起多个长连接，增加了任务队列。

• RFC2616 里明确限制每个客户端最多并发 2 个连接
• 不过实践证明这个数字实在是太小了，众多浏览器都“无视”标准，把这个上限提高到了 6~8。后来修订的RFC7230 也就“顺水推舟”，取消了这个“2”的限制。
• Chrome中是6个

3.1.4.2 域名分片

并发连接所压榨出的性能也跟不上高速发展的互联网无止境的需求
举个例子，公司发展的太快，员工越来越多，上下班打卡都成了问题。前台空间有限，上下班时会排起长队，怎么办？ 那就分流，多设置几个打卡机分布在公司。
这其实也就是域名分片技术。
比如xzqcloud.com ,可以分出很多二级域名，s1.xzqcloud.com, s2.xzqcloud.com，这样实际长连接的数量又上去了

3.2 HTTPS协议

HTTPS = HTTP + SSL/TLS

3.2.1 TLS/SSL工作原理

HTTPS协议的主要功能都基本依赖于TLS/SSL协议，TLS/SSL的功能实现主要依赖于三类基本算法： 哈希摘要，对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整新。

HTTPS其实就是基于这三种加密算法完成安全传输。

3.2.1 对称加密

对称加密就是加密和解密使用同一把密钥
常见的对称加密有： AES,DES。

3.2.1 非对称加密

非对称加密就是： 加密和解密使用不同的密钥，非对称加密需要两把密钥，一把公钥一把私钥，公钥加密，私钥解密，私钥加密，公钥解密。
常见的非对称加密算法： RSA ,ECC

3.2.1 摘要算法

摘要算法是通过一系列的计算方法和规则，将输入的任意长度的数据转化为固定长度的返回值，这个值被称为hash值，而这种算法被称为摘要算法，哈希算法，散列算法。
常见的摘要算法：
MD5 生成128位固定长度的hash值
SHA-1 生成164为固定长度的hash值
SHA-2 生成224,256,384,512的hash值
SHA-3 全新的算法和标准

而HTTPS的TLS/SSL是如何使用这三种加密算法完成安全传输呢

Case1:
对称加密
如果使用对称加密的话，那么首先需要规定密钥，而密钥的传输在网络中是不安全的既有可能被中间人捕捉，使得加密信息没有意义，那么如何解决呢？
Case2
非对称加密，使用非对称加密的话，私钥留在服务端，公钥下发客户端，中间人是获取不到私钥的，但是还有一个问题，那就是伪造信息，既中间人捕获服务端发送的公钥，将自己的公钥给客户端，客户端拿到中间人的公钥进行加密，中间人就可以使用自己的私钥来解密。
Case3
所以下发的公钥需要具有信任度，这就需要第三方机构介入（CA机构） ，既客户端拿到公钥之后需要验证其公钥的可信度。

那么HTTPS的流程是怎么样的呢？
首先客户端请求公钥证书，服务端返回公钥证书，客户端验证证书，验证通过，使用公钥对伪随机数进行加密（会话密钥）传输给服务端，服务端使用私钥解密拿到会话密钥，就可以使用会话密钥对明文进行加密。