HTTP/HTTPS/TCP

HTTP协议

• TCP/IP 协议族：
  TCP/IP 协议族是Internet最基本的协议，HTTP协议是它的一个子集。TCP/IP协议族按层次分为以下四层：
  • 应用层：向用户提供应用服务时通信的协议，FTP(文件传输协议)和DNS(域名系统)服务就是其中的两类
  • 传输层：传输层对接上层应用层，在传输层有两个性质不同的协议：TCP和UDP；
    
    • TCP协议是全双工的，即发送数据和接收数据是同步进行的，TCP协议在建立和断开连接时有三次握手和四次挥手，因此在传输的过程中更稳定可靠但同时就没UDP那么高效了;
    • UDP协议是面向无连接的，UDP协议不保证有序且不丢失的传递到对端，也就是说不够稳定，但也正因如此，UDP协议比TCP更加高效和轻便;
  • 网络层：网络层规定了数据通过怎样的传输路线到达对方计算机传送给对方（IP协议等）
  • 链路层：用来处理连接网络的硬件部分，包括控制操作系统、硬件的设备驱动、NIC（网络适配器，即网卡），及光纤等物理可见部分，硬件上的范畴均在链路层的作用范围之内
• HTTP/1.0:短连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接
• HTTP/1.1:长连接，加入keep-alive后实现长连接，如果开启 keep-alive，则服务端在返回 response 后/客户端接收完响应报文后不关闭TCP连接；在 HTTP/1.1协议中，默认开启keep-alive
• HTTP/2.0多路复用：每个HTTP请求都有一个序列标识符，这样浏览器可以并发多个请求，服务器接收到数据后，再根据序列标识符重新排序成不同的请求报文，而不会导致数据错乱；同样，服务端也可以并发返回多个响应给浏览器；并且同一个域名下的所有请求都复用同一个TCP连接，极大增加了服务器处理并发的上限
• WebSocket：WebSocket是HTML5提出的一种客户端和服务端通讯的全双工协议，由客户端发起请求，建立连接之后不仅客户端可以主动向服务端发送请求，服务端可以主动向客户端推送信息
• HTTP/3.0：HTTP/2.0使用了多路复用，一般来说同一域名下只需要使用一个TCP连接，但当这个连接中出现了丢包的情况，那就会导致整个TCP都要开始等待重传，也就导致了后面的所有数据都被阻塞了。Google基于UDP协议推出了一个的 QUIC 协议，并且使用在了HTTP/3上，QUIC主要特点如下：
  1. 避免包阻塞：在基于UDP的QUIC协议中，不同的流之间的数据传输真正实现了相互独立互不干扰，某个流的数据包在出问题需要重传时，并不会对其他流的数据包传输产生影响
  2. 快速重启会话：普通基于tcp的连接，是基于两端的ip和端口和协议来建立的。在网络切换场景，例如手机端切换了无线网，使用4G网络，会改变本身的ip，这就导致tcp连接必须重新创建。而QUIC协议使用特有的UUID来标记每一次连接，在网络环境发生变化的时候，只要UUID不变，就能不需要握手，继续传输数据

HTTPS

HTTP是明文传输协议，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全

• 加密方式：对称加密+非对称加密
  • 在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式
• 数字签名:解决报文可能遭篡改问题
  • 将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者
• 数字证书:解决通信方身份可能被伪装的问题
  • 数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上
• HTTPS请求流程：
  1. 客户端发起一个HTTPS的请求；
  2. 服务端把事先配置好的公钥证书返回给客户端
  3. 客户端验证公钥证书，如果验证通过则继续，不通过则显示警告信息；
  4. 客户端生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给服务端
  5. 服务端使用自己的私钥解密这个消息，得到对称密钥，至此，客户端和服务端双方都持有了相同的对称密钥
  6. 服务端使用对称密钥加密“明文内容A”，发送给客户端；客户端使用对称密钥解密响应的密文，得到“明文内容A”
• HTTP与HTTPS的区别
  • HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页；
  • HTTPS需要用到SSL证书
  • HTTPS标准端口443，HTTP标准端口80
  • HTTPS基于传输层，HTTP基于应用层
  • HTTPS在浏览器显示绿色安全锁，HTTP没有显示

TCP

• 三次握手流程：
  1. 客户端发送SYN，表明要向服务器建立连接。同时带上序列号ISN
  2. 服务端返回ACK（序号为客户端序列号+1）作为确认。同时发送SYN作为应答（SYN的序列号为服务端唯一的序号）
  3. 客户端发送ACK确认收到回复（序列号为服务端序列号+1）
• 为什么是三次握手
  • 第一次握手：证明了发送方能发数据
  • 第二次握手：ack确保了接收方能收数据，syn确保了接收方能发数据
  • 第三次握手：确保了发送方能收数据
  • 四次握手浪费，两次握手不能保证双方同时具备收发功能
• 四次挥手流程：
  1. 客户端发送FIN，表示要单方面关闭数据的传输
  2. 服务端收到后，发送一个ACK作为确认（序列号为收到的序列号+1）
  3. 等服务器数据传输完毕，服务端也发送一个FIN标识，表示关闭这个方向的数据传输
  4. 客户端回复ACK以确认回复
• 为什么是四次挥手
  • tcp支持半关闭（发送一方结束发送还能接收数据的功能）
  • 因此每个方向都要单独关闭，且收到关闭通知需要发送确认回复
• time_wait状态
  • 也称为2MSL等待状态，报文段最大生存时间，根据不同的tcp实现自行设定。常用值为30s，1min，2min。linux一般为30s
  • 主动关闭的一方发送最后一个ack所处的状态，这个状态必须维持的等待时间
  • 该状态是为了防止最后这个ack丢失了，接收方没有收到，让发送方重新发送ack
  • 但是在这2MSL等待时间内，该连接将不能被使用，多并发的短连接情况下，会出现大量的Time_wait状态，很多时候linux上报too many open files ，说端口不够用了，就需要检查一些代码里面是不是创建大量的socket连接，而这些socket连接并不是关闭后就立马释放的，如果是服务端开发，可设置keep-alive，让客户端主动关闭连接解决这个问题
• 滑动窗口协议
  • 发送方和接收方速率不匹配时，保证可靠传输和包乱序的问题
  • 接收方根据目前缓冲区大小，通知发送方目前能接收的最大值。发送方根据接收方的处理能力来发送数据。通过这种协调机制，防止接收端处理不过来
• 超时与重传
  • tcp通过在发送时设置定时器解决数据和确认可能丢失的问题，定时器时间到了还没收到确认，就重传该数据
• 主动的快速重传机制
  • 如果包没有送达，就一直ack最后那个可能被丢的包，发送方连续收到相同的ack，就重传，不用等待超时
• SACK
  • 基于快速重传，同时在tcp头里加了一个SACK的东西,SACK记录一个数值范围，表示哪些数据收到了,解决了客户端应该发送哪些超时包的问题
• 超时重传引发的问题-拥塞
  • 当网络延迟突然增加时，tcp会重传数据，但是过多的重传会导致网络负担加重，从而导致更大的延时和丢包，进入恶性循环
  • 解决办法：
    1. 慢启动：降低分组进入网络的传输速率
    2. 拥塞避免：处理丢失分组的算法
    3. 快速重传/恢复