TCP/IP协议

三次握手和四次挥手

• 三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

• 四次挥手

第一次挥手：客户端发出断开连接报文，等待断开连接，处于wait1状态
第二次挥手：服务器收到断开报文，状态更为close-wait状态，并发送准备断开报文。
第三次挥手：客户端收到断开报文，状态变为wait2。服务端继续发送断开本文进入last-ack状态
第四次挥手：客户端收到第二次断开报文，向服务器发送确认断开报文。进入time-wait状态。服务器收到报文关闭，客户端等待2msl后关闭。

其中SYN是同步报文。ACK是响应报文。因为服务器收到关闭报文时，并不会直接关掉，而且先发送同步报文，在发送关闭报文。所以才会比三次握手多一次。
MSL指的是最大发送和响应时间差。如果客户端facing最后发送关闭报文，等待2msl没有在收到报文则认为服务器已关闭，才会关闭。

HTTP协议

通俗的说：http协议通常是跑在TCP/IP的协议栈之上，依靠IP实现寻址和路由、TCP协议实现可靠数据传输、DNS协议实现域名查找、SSL/TLS协议实现安全通信。此外，有一些协议依赖于HTTP如WebSocket、HTTPDNS等。

HTTP专门用于在两点之间传输数据，不能用于广播、寻址和路由。
HTTP传输的是文字、图片、音频、视频等超文本数据。
HTTP是一个超文本传输协议

什么是超文本

即潮语了普通文字的文本，是文字、音频、图片、视频、超链接的混合体，最常见是HTML

什么是传输

就是将某些东西从A移动到B

什么是协议

协议就是一种规范

优点

1. HTTP 最大的优点是简单、灵活和易于扩展;
2. HTTP 拥有成熟的软硬件环境，应用的非常广泛，是互联网的基础设施;
3. HTTP 是无状态的，可以轻松实现集群化，扩展性能，但有时也需要用 Cookie 技术来实
   现“有状态”;
4. HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听;
5. HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被窜改;
6. HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间。

总结

HTTP 是一个在计算机世界 里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

HTTPS

HTTPS 就相当于这个比喻中的“火星文”，它的全称是“HTTP over SSL/TLS”，也就是运行在 SSL/TLS 协议上的 HTTP。注意这里是SSL/TLS协议而不是TCP/IP协议，SSL/TLS也是基于TCP/IP协议之上做了一次加密，所以也是个可靠的传输协议。

SSL/TLS

SSL 的全称是“Secure Socket Layer”，由网景公司发明，当发展到 3.0 时被标准化，改名为 TLS，即“Transport Layer Security”，但由于历史的原因还是有很多人称之为 SSL/TLS，或者直接简称为 SSL。

SSL使用了许多密码学的先进成果，综合了对称加密(AES)、非对称加密(RSA)、摘要算法、数字签名、数字证书等。能够在不安全的环境中为通信的双方创建一个秘密的、安全的传输通道。

TLS协议的组成(记录协议+警报协议+握手协议+变更密码规范协议)

**记录协议(Record Protocol)：规定了TLS收发的基本单位：记录(record)。**他有点像TCP里的segment，所有的其他子协议都需要记录协议发出。但是多个记录数据可以在一个TCP包里一次性发出，也并不需要想TCP那样返回ACK。
**警报协议(Alert Protocol)：职责是向对方发出警报信息，有点像HTTP协议里的状态码。**比如，protocol_version就是不支持旧版本，bad_certificate就是证书有问题，收到警报之后另一方可以选择继续也可以立即终止。
握手协议(Handshake Protocol)：TLS最复杂的子协议，要比TCP的SYN/ACK复杂的多，浏览器和服务器会在握手过程中协商TLS版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商会得到会话密钥，用于后续的混合加密系统
变更密码规范协议(Change Cipher Spec Protocol)： 就是一个‘通知’告诉对方，后续的数据都将使用加密保护。那么反过来，在他之前，数据都是明文的。

TLS握手的过程简介

详细ECDHE握手过程

1、client发送"client hello"消息，里面包含客户段版本号、支持的密码套件，还有随机数（client random），用户生成会话密钥
2、服务器返回一个"server hello"消息，对一下版本号，也给出一个随机数(server random)，然后从客户端的给的密码套件列表里选择一个套件。这里服务器选择了"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"。
3、服务器为了证明自己的身份，把证书发送给客户端(server certificate)。因为服务器选择了ECDHE算法，所以会在证书发送后发送"server key change" 消息，里面是椭圆曲线的公钥(server params)，用来实现密钥交换算法，再加上自己的私钥签名认证。相当于说：刚才选的密码套件有点复杂，所以再给你个算法的参数，和刚才的随机数一样有用。为了防止别人冒充，我又改了个章。
4、之后就是"server done"
5、这里客户端拿到服务区证书，逐级验证，确认证书的真实性，在用证书共钥验证签名。全部通过客户端也按密码套件要求生成一个椭圆曲线的公钥(client parmas),用client key change发送给服务器。
6、现在客户端和服务器都拿到了密钥交换算法的两个参数(client parmas、server parmas)，就用ECDHE算法一阵算，算出一个叫“pre-master”，其实也是一个随机数。
7、现在客户端服务器手中有三个随机数：client random、server random、pre-master。用这三个就可生成用于加密会话的主密钥，叫mater-secret。

协议分层模型

TCP/IP

第一层：链接层，负责在以太网、wifi这样的底层网络上发送原始数据包，工作在网卡这个层次，使用MAC地址来标记网络上的设备，也叫MAC层
第二层：网际层或者网络互联层，IP协议在这一层
第三层：传输层，TCP/UDP，可靠的传输数据
第四层：应用层，Telnet、SSH、FTP、 SMTP 等等，当然还有我们的 HTTP

OSI

全称是“开放式系统互联通信参考 模型”(Open System Interconnection Reference Model)

第一层：物理层，网络的物理形式，例如电缆、光纤、网卡、集线器等等;
第二层：数据链路层，它基本相当于 TCP/IP 的链接层;
第三层：网络层， 相当于 TCP/IP 里的网际层;
第四层：传输层，相当于 TCP/IP 里的传输层;
第五层：会话层，维护网络中的连接状态，即保持会话和同步;
第六层：表示层，把数据转换为合适、可理解的语法和语义;
第七层：应用层，面向具体的应用传输数据。

一个HTTP的请求过程

1、DNS域名解析出ip地址和端口
2、浏览器TCP三次握手与服务器建立连接
3、浏览器向服务器发送拼好的报文
4、服务器收到报文处理请求，同样拼好报文发给浏览器
5、浏览器解析报文，渲染出界面

二层转发以及三层路由

二层转发：二层指的是数据链路层，工作在二层的设备，通过查找目标MAC地址进行数据妆发
三层路由：三层指的是网络层，工作在三层的设备，通过解析数据包头信息，找到目标IP地址转发数据。

HTTP/1

HTTP/1.0

短连接：每次请求都需要重新建立和销毁TCP连接

HTTP/1.1

特性

默认长连接：建立一次TCP连接后，后面的连接可以服用。

队头阻塞问题

队头阻塞问题不是因为长连接和短连接引起的。而是由HTTP“请求-响应”模式造成的。因为HTTP规定报文必须是一收一发。就形成了先进先出的队列。队列里请求没有轻重缓急的优先级，只有入队的先后顺序。如果队首的请求因为处理的太慢耽误了时间，那么后面的请求不得不等待，结果就是其他的请求承担不了相应的时间成本。

HTTP/2

在HTTP/1时代可分为，HTTP/1.0和HTTP/1.1。后来因为1.0、1.1这种小版本号容易造成误解就取消小版本号该用大版本号。

• 改变

HTTP/1可以用头字段“Content-Encoding”指定Body的编码方式，比如gzip来压缩节约带宽。但是报文的另一个组成部分header却被忽视。由于header会懈怠user_agent、cookie、accept、server等固定头字段多达上百甚至上千字节，而body却经常带有几十字节。这会导致大量带宽消耗在这些冗余度极高的数据上。

所以HTTP/2吧“头部压缩”作为性能改进的一个重点。方式还是压缩。不过并没有使用传统的压缩算法，而是开发了专门的HPACK算法，在客户端和服务器建立“字典”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数解和字符串，可以达到50%～90%的高压缩率。

HTTP/2不再采用和HTTP/1一样的纯文本报文，而是靠近传输层TCP/IP协议采用二进制。为此定义了一个流的概念，他是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的ID流，一串有先后顺序的数据帧组装起来就是HTTP/1中的请求和响应报文。

因为流是虚拟的，实际并不存在。所以HTTP/2就可以在一个TCP连接上用流发送多个消息。就是常说的多路复用---------多个往返通信都服用一个连接来处理。在流的层面看，消息是一些有序的帧序列，而在连接层面看，消息却是乱序收发的帧。多个请求/响应之间没有了顺序关系，不需要排队等待就不会出现对头阻塞问题，降低了延迟提高了连接利用率。

1. HTTP/2 完全兼容 HTTP/1，是“更安全的 HTTP、更快的 HTTPS”，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验;
2. TCP 协议存在“队头阻塞”，所以 HTTP/2 在弱网或者移动网络下的性能表现会不如 HTTP/1;
3. 迁移到 HTTP/2 肯定会有性能提升，但高流量网站效果会更显著;
4. 如果已经升级到了 HTTPS，那么再升级到 HTTP/2 会很简单;
5. TLS 协议提供“ALPN”扩展，让客户端和服务器协商使用的应用层协议，“发
   现”HTTP/2 服务。

websocket

websocket针对的是“请求-应答”的通信模式

请求应答是一种半双工通信模式，虽然可以双向收发数据，但是同一时刻只能一个方向上有动作，传输效率低。更关键的是，它是一种被动的通信模式，服务器只能被动的响应客户端的请求，无法主动向客户端发送数据。
虽然后来HTTP/2、HTTP3信者了Sream、server push等特性，但请求-响应依然是主要的工作方式，这就导致HTTP难以应用在动态页面、即时消息、网络游戏等要求实时通信的领域。想要是知道服务器的数据。就需要一直请求，即我们所畏的轮询。缺点特别明显，反复发送耗费了大量的宽带和CPU资源。为了克服这种缺点，websocket应用而生。

特性

websocket采用了二进制帧结构，语法和语义与HTTP完全不兼容。因为其主要运行环境是浏览器，为了便于推广，在使用习惯上尽量向HTTP靠拢。

websocket沿用http的URI格式，协议名为“ws”和“wss”分别表示明文和加密的websocket协议。默认的端口采用80和443。因为互联网防火墙大部分只对80和443放行。

websocket帧头：结束标志位 (FIN)+ 操作码(Opcode) + 帧长度(Payload len) + 掩码(掩码密钥，它是由上面的标志位“MASK”决定的， 如果使用掩码就是 4 个字节的随机数，否则就不存在)

1. HTTP 的“请求 - 应答”模式不适合开发“实时通信”应用，效率低，难以实现动态页 面，所以出现了 WebSocket;
2. WebSocket 是一个“全双工”的通信协议，相当于对 TCP 做了一层“薄薄的包装”， 让它运行在浏览器环境里;
3. WebSocket 使用兼容 HTTP 的 URI 来发现服务，但定义了新的协议 名“ws”和“wss”，端口号也沿用了 80 和 443;
4. WebSocket 使用二进制帧，结构比较简单，特殊的地方是有个“掩码”操作，客户端 发数据必须掩码，服务器则不用;
5. WebSocket 利用 HTTP 协议实现连接握手，发送 GET 请求要求“协议升级”，握手 过程中有个非常简单的认证机制，目的是防止误连接。

如果您觉得文章对您有所帮助，可以请囊中羞涩的博主吃个鸡腿饭，万分感谢。愿每一个来到这里的人生活幸福美满。

微信赞赏

支付宝赞赏