[网络协议]网络基础复习

?网络协议所在的层

HTTP HTTP2 应用层协议

TCP UDP 运输层

IP 网络层

Ethernet 物理层

IP协议主要解决网络路由和寻址问题

TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另一端收到发端发出的所有包，并且顺序与发出顺序一致。

HTTP与WebSocket

HTTP

HTTP是单向的，客户端发送请求，服务器发送响应。

当客户端向服务器发送请求时，该请求以HTTP或HTTPS的形式发送，在接收到请求后，服务器会将响应发送给客户端。

每个请求都与一个对应的响应相关联，在发送响应后客户端与服务器的连接会被关闭。

每个HTTP或HTTPS请求每次都会新建与服务器的连接，并且在获得响应后，连接将自行终止。?

HTTP是在TCP之上运行的无状态协议，TCP是一种面向连接的协议，它使用三向握手方法保证数据包传输的传递并重新传输丢失的数据包。

当客户端将HTTP请求发送到服务器时，客户端和服务器之间将打开TCP连接，并且在收到响应后，TCP连接将终止，每个HTTP请求都会建立单独的TCP连接到服务器，例如如果客户端向服务器发送10个请求，则将打开10个单独的HTTP连接。并在获得响应后关闭。

HTTP长连接和短连接

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

每个HTTP连接完成后，其对应的TCP连接并不是每次都会关闭。

从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这个头部字段：Connection:keep-alive。

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。

Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache，Nginx，Nginx中这个默认时间是 75s）中设定这个时间。

实现长连接要客户端和服务端都支持长连接。

WebSocket

WebSocket是双向的（基于HTTP协议，使用 101 状态码来切换协议），在客户端-服务器通信的场景中使用的全双工协议，与HTTP不同，它以ws://或wss://开头。

每当我们启动客户端和服务器之间的连接时，客户端-服务器进行握手随后创建一个新的连接，新建的连接被称为WebSocket。

一旦通信链接建立和连接打开后，消息交换将以双向模式进行，客户端-服务器之间的连接会持续存在。

如果其中任何一方（客户端服务器）宕掉或主动关闭连接，则双方均将关闭连接。

套接字的工作方式与HTTP的工作方式略有不同，状态代码101表示WebSocket中的交换协议。

HTTP长连接与WebSocket：

HTTP长连接有保持时间，而WebSocket连接直到服务器或客户端任何一方宕掉或主动关闭连接才关闭连接。

使用情景：

WebSocket：通过网络传输实时更新或连续数据流时使用。

HTTP：不需要很频繁或仅获取一次数据时使用。

三次握手和四次挥手

seq：报文编号
SYN ： 表示建立连接
FIN： 表示关闭连接
ACK: ?表示是否响应（1表示响应）
ack ：表示响应的报文编号+1

三次握手：

确认客户端和服务器的双工性：确定客户端和服务器都有发送和接受报文的能力。

防止网络延时造成的服务器阻塞：如果是两次的话，网络延时导致SYN报文发送两次，使服务器与服务端二次建立连接。

四次挥手：

1.客户端发送一个 FIN 报文，即发出连接释放报文段，并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

2.服务端收到 FIN 之后，会发送 ACK 报文，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

3.如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文。此时服务端处于 LAST_ACK 的状态。

4. 客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，此时客户端处于 TIME_WAIT 状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态，以确保服务端收到自己的 ACK 报文。服务端收到 ACK 报文之后，关闭连接，进入于 CLOSED 状态。

close_wait

close_wait出现在被动关闭方

被动方未及时释放端口资源导致

time_wait

保证TCP协议的全双工连接能够可靠关闭：

为了保证A发送的最后一个ACK报文能够到达B。

这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。

B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。

如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。

这样，B就无法按照正常的步骤进入CLOSED状态。?

保证连接的重复数据段（被动关闭方的fin报文）从网络中消失

A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。

这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。?

tcp流量控制和拥塞控制

udp不需要，不建立连接

流量控制：

通讯双方网速不一样，任何一方发送过快都会导致对方消息处理不过来，所以要把数据放到缓冲区中。

如果缓冲区满了，发送方还在发送，那么接收方就会把数据包丢弃，因此需要控制发送速率

缓冲区剩余大小称为接收窗口，用变量win表示，如果win为零，那么发送方就停止发送。

缓冲和缓存：

缓冲，存放处理不过来数据，缓和冲击。通俗：吃饭吃不完打包

缓存，加快取用的速度，将常用的数据存到能快速获取的区域。 通俗：把爱吃的菜摆在手边，方便夹。

宏观上说两者可能是混用的。

Buffer的核心作用是用来缓冲，缓和冲击。

缓冲是指在数据流转过程中,不同层次速度不一致时,利用缓冲区来缓解上下层之间速率问题。

比如你每秒要写100次硬盘，对系统冲击很大，浪费了大量时间在忙着处理开始写和结束写这两件事。

用个buffer暂存起来，变成每10秒写一次硬盘，对系统的冲击就很小，写入效率高了，极大缓和了冲击。

Cache的核心作用是加快取用的速度。

把常用数据存储到可以快速获取的区域,以备重复利用,一般叫做cache， 缓存能提高效率。

?拥塞控制：

与流量控制是两个概念，拥塞控制是调节网络负载。

接收方网络繁忙，因未及时响应ACK，导致发送方以为数据丢失，再次发送大量数据。这样使网络更加拥堵。

拥塞控制是动态调整win的大小，不只是依赖缓冲区的大小确定窗口大小。

拥塞控制包括两部分：

慢开始和拥塞避免

慢开始：指数规律提速（通过增大win窗口大小），试探网络的承受能力。

拥塞避免：达到慢开始的阈值后，进入拥塞避免阶段，每次传输增加1个窗口。

?

快速重传和快速恢复

当到达网络负载上限（开始丢包）时，接收方每收到一个失序的报文段就立即发出重复确认（3个重复ACK）来通知发送方，发送方收到3个重复ACK后，快重传丢失的报文，并开始快速恢复。?

快恢复：把网络负载上限减半作为起点，进入拥塞避免阶段，每次传输增加1个窗口。

粘包、拆包

发生在应用程序到缓冲区过程中的

应用程序写入的数据大于套接字缓冲区大小，将发生拆包。

发生在tcp服务过程中的

待发送的数据>MSS的时候，TCP在传输前将进行拆包。MSS（最大报文长度）

接受方不及时读取套接字缓冲区数据，这将发生粘包

要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

解决方法：

1. 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
2. 发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
3. 可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

httpserver处理流程：

httpserver-->http请求-->url-->根据url-->处理函数、对象-->处理结果-->httpServer Socket-->客户端 ?

网络代理：

正向代理：

正向代理即是客户端代理,? 服务端不知道实际发起请求的客户端（VPN）

正向代理类似一个跳板机，代理访问外部资源

1. 访问原来无法访问的资源，如google
2. 可以做缓存，加速访问资源
3. 对客户端访问授权，上网进行认证
4. 代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

反向代理：

反向代理即是服务端代理, 客户端不知道实际提供服务的服务端

意义：

1. 保证内网的安全，阻止web攻击，大型网站，通常将反向代理作为公网访问地址，Web服务器是内网。
2. 负载均衡，通过反向代理服务器来优化网站的负载。

网络转发和网络代理

网络转发：是路由器对报文的转发操作，中间可能对数据包修改。（客户端的目标ip是实际服务器）

网络代理：用户不直接连接服务器，网络代理去连接，获取数据后返回给用户。（客户端的目标ip是代理地址）
?

HTTP和HTTPS

HTTP：HTTP是超文本传输协议，以明文方式发送内容，不提供任何方式的数据加密，不适合传输一些敏感信息。

HTTPS： HTTPS是安全套接字层超文本传输协议，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS和HTTP的区别主要如下：

1. https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2. http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS工作原理：

HTTPS采用不对称加密JK+对称加密B

服务器将不对称密钥K交给浏览器（客户端），客户端给服务器一个对称密钥B,之后就通过这个B来进行加密通信。

HTTP1/ 1.1/ 2/ 3?

HTTP协议是HyperText Transfer Protocol（超文本传输协议）的缩写，它是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。伴随着计算机网络和浏览器的诞生，HTTP1.0也随之而来，处于计算机网络中的应用层.

HTTP1

HTTP/1.0引入了请求头和响应头。

同时也引入了状态码，为了减轻服务器的压力，提供了Cache机制。服务器需要统计客户端的基础信息，加入了用户代理字段。

HTTP1.1

支持长连接

请求头中增加connection: keep-alive支持，针对同一个tcp进行复用，减少tcp握手带来的时间。

缓存处理

缓存头中提供了更多的属性来支持不同的缓存策略。在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

增加对虚拟主机的支持（Host头处理）

HTTP/1.0中每个域名都只绑定唯一的IP地址，因此一个服务器只能支持一个域名。

但是随着虚拟主机技术的发展，一台物理主机上绑定多个虚拟主机的需求大大提升，每个虚拟主机都有自己单独的域名，这些单独的域名都公用同一个IP地址。

因此，请求头中也增加了Host字段，表示当前的域名地址，服务器可根据不同的Host值做不同的处理，支持同一个IP下的不同服务器提供服务。

错误通知的管理

在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

带宽优化及网络连接的使用

HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。

HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

SPDY：HTTP1.x的优化

SPDY的方案优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

1. 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。

2. 请求优先级。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。

3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。

4. 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。

5. 服务端推送，采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。SPDY构成图：

HTTP2

HTTP2是基于SPDY设计的，是SPDY的升级版。

、HTTP2.0和HTTP1.X相比的新特性

• 新的二进制格式，HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

• 二进制分帧，在二进制分帧层上，HTTP 2.0 会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码 。
  
  这样分帧以后这些帧就可以乱序发送，然后根据每个帧首部的流标识符号进行组装。

• 多路复用，同域名下多个通信可以在单个连接上完成；单个连接可以承载任意数量的双向数据流；数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，最后根据帧首部的流标识可以重新组装。某个请求任务耗时严重，不会影响到其它连接的正常执行。

• header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

• 服务端推送?，同SPDY一样，HTTP2.0也具有server push功能。

HTTP2.0和SPDY的区别：

1. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS。（HTTP不加密）

2. HTTP2.0 消息头的压缩算法采用?HPACK ，而非 SPDY 采用的?DEFLATE 。

HTTP3

由于HTTP1 HTTP1.x HTTP2都是基于TCP开发的，其中的TCP握手问题就无法避免，为了解决这个问题，Google 就另起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上。其特点主要为：

• 0-RTT，RRT即客户端与服务器之间通讯来回一次所花费的时间，通过QUIC协议可以实现在客户端向服务端发起一次QUIC握手的同时即可完成验证及进行数据的传输，实现了0-RRT。
• 多路复用，基于UDP实现的多路复用，不存在TCP中的阻塞现象。
• 加密认证的报文，所有报文头经过了验证，所有报文body经过加密，提高安全性。
• 向前纠错机制，在传输过程中每个数据包会冗余其他数据其他少量的数据包数据，如果一个包出现了丢包的情况，可以通过其他数据包的数据恢复，在一定程度上降低了错误重传导致的开销。