网络协议基础

URI 和 URL 的区别

URI(统一资源标识符)全称是 Uniform Resource Identifier,用来唯一标识一个资源,格式如下:scheme://host:port/path

URL(统一资源定位器)是 Uniform Resource Locator,它是一种具体的 URI

HTTP 超文本传输协议(Hypertext Transfer Protocol)

  • 应用层协议
  • 基于 TCP 实现
  • 协议简单
  • 无状态:对上次访问无记忆
  • 无连接:请求结束后关闭当前连接,用于节省服务器资源,但在多次网络请求时性能较差(TCP 握手、慢启动),HTTP1.1 版本加入了 keep-alive 来解决该问题

HTTP 请求方法

  • HTTP 1.0 定义了三种请求方法:GET、POST、HEAD
  • HTTP 1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE、CONNECT
序号方法描述
1GET请求指定的页面信息,并返回实体主体
2HEAD类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头
3POST向指定资源提交数据进行处理请求,例如提交表单或者文件,数据被包含在请求体中
4PUT从客户端向服务器传送的数据取代指定的文档的内容
5DELETE请求服务器删除指定的页面
6CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
7OPTIONS允许客户端查看服务器的性能
8TRACE回显服务器收到的请求,主要用于测试或诊断
9PATCH是对 PUT 方法的补充,用来对已知资源进行局部更新

Request Header

  • 请求行(请求方法 / 文件路径 / 协议版本)
  • Host(主机地址)
  • Accept-Encoding(本地接受的压缩方式)
  • Content-Type(数据格式)
  • Connection(keep-alive、upgrade)
  • If-None-Match(配合 Etag 使用,返回304码),1.1版本引入
  • If-Modified-Since(1.0 版本,本地资源时间戳)

Response Header

  • 状态行(协议版本 / 返回码 / 返回码描述)
  • Content-Type(数据格式)
  • Content-Encoding(压缩方式)
  • Content-Length(数据长度)
  • Proxy-Connection(keep-alive,保持 TCP 链接),1.1版本引入
  • Cache-Control(max-age / no-cache),1.1版本引入
  • Etag(资源Hash值),1.1版本引入
  • Last-Modified(1.0版本,资源修改时间)
  • Pragma / Expires(1.0版本,指定时间使用本地缓存)

Get 请求

  • 数据放在请求行的 Path 中(通过 ? 分隔,通过 & 连接不同参数),会被浏览器缓存
  • 请求长度最多为 1024kb(部分浏览器及服务器的限制)
  • GET 请求只能进行 URL 编码(Urlencode 键值对)

Post 请求

  • 数据放在 Request Body 中,不会被浏览器缓存
  • 没有数据大小的限制
  • POST 请求支持多种编码方式(Protobuf、Json、Urlencode)

HTTP 协议无状态问题

Cookie / Session、Token 解决了 HTTP 协议无状态的问题,但是在实现上存在一定的差异

  1. Cookie

    • Cookie是一种在客户端和服务器之间传递信息的机制,通常用于在浏览器和服务器之间存储会话信息、用户首选项、跟踪信息等。
    • 服务器在响应中通过Set-Cookie头部将Cookie发送给客户端,客户端在后续的请求中会自动将该Cookie发送回服务器。
    • Cookie通常用于实现会话管理,可以存储会话标识符、用户身份验证信息等,以便服务器能够识别和管理用户的会话状态。
  2. Session

    • Session是一种服务器端存储用户会话信息的机制,用于跟踪用户的会话状态。
    • 当用户登录时,服务器会为用户创建一个会话,并将会话信息存储在服务器端的内存、数据库或缓存中。
    • 服务器会生成一个唯一的会话标识符(Session ID),并将其发送给客户端,通常存储在Cookie中。
    • 客户端在后续的请求中会将该会话标识符发送给服务器,服务器通过会话标识符来识别和管理用户的会话状态。
  3. Token

    • Token是一种用于身份验证和授权的令牌,通常使用JSON Web Token (JWT)来实现。
    • 当用户登录时,服务器会生成一个包含用户信息和有效期等信息的令牌,并将其发送给客户端。
    • 客户端在后续的请求中会将该令牌包含在请求的头部或参数中发送给服务器。
    • 服务器通过验证令牌的签名和有效期来验证用户身份,并根据令牌中包含的信息来进行授权。

主要区别:

  • 存储位置:Session的会话信息存储在服务器端,而Cookie、Token的会话信息存储在客户端。
  • 传递方式:Cookie通过HTTP头部传递,Session通常通过Cookie传递会话标识符,而Token可以通过请求头部或参数传递。
  • 依赖关系:Cookie和Session依赖于浏览器对Cookie的支持,而Token是无状态的,不依赖于客户端状态。

HTTPS 是在 HTTP 层和 TCP 层新增了 SSL / TLS 协议,实现了信息加密、身份校验等功能

对称加密算法(如AES、DES)、非对称加密算法(如RSA)、哈希算法(MD5、SHA(Secure Hash Algorithm)- 1、2、3)

TLS(Transport Layer Security) 四次握手

  • 第一步,客户端向服务器发起请求,请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。

  • 第二步,服务器端接收到请求后,确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。

  • 第三步,客户端确认服务器证书有效后,生成一个新的随机数,并使用数字证书中的公钥,加密这个随机数,然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值,用来供服务器检验。

  • 第四步,服务器使用自己的私钥,来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。

  • 第五步,客户端和服务器端根据约定的加密方法使用前面的三个随机数,生成对话秘钥,以后的对话过程都使用这个秘钥 来加密信息。

数字证书(主要用来保证公钥的正确性):证书的有效期、证书所有者、公钥、加密算法、证书的发布机构、指纹以及指纹算法,意味着证书信息需要上级证书证明(追溯到跟证书)

HTTPS 相对 HTTP 较慢,主要是因为增加了 TLS 握手数据加密逻辑

HTTP/1.1 相比 HTTP/1.0 性能上的改进

  • 使用 KeepAlive 方式改善了 HTTP/1.0 短连接造成的性能开销
  • 支持 Pipeline 模式,允许客户端在已发送的请求收到响应前发送下一个请求
  • 增加 ETag 和 Cache-control 缓存策略

HTTP/1.1 性能瓶颈

  • 请求 / 响应 Header 未压缩,首部信息越多延迟越大,只能压缩 Body 的部分
  • 由于没有序号机制,服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据,也就是队头阻塞
  • 没有请求优先级控制
  • 请求只能从客户端开始,服务器只能被动响应

HTTP/2 相比 HTTP/1.1 性能上的改进

  • 头部压缩(客户端和服务端同时维护头部信息表)
  • 二进制格式(头信息帧和数据帧)
  • Stream 并发(同一个连接的数据包,可能属于不同的 Response,且存在优先级关系)
  • 服务器推送(客户端在请求一个页面时,服务端提前下发页面中包含的其他资源,比如 index.html 中的超文本)

HTTP/2 性能瓶颈

  • 由于多个 HTTP 复用一个 TCP 连接,如果存在丢包的现象,则所有 HTTP 请求都要等待失败重传,所以也存在队头阻塞的问题

HTTP/3 相比 HTTP/2 性能上的改进

  • 传输层协议从 TCP 改为了 UDP,解决了队头阻塞和慢启动问题
分类分类描述
1**信息,服务器收到请求,需要请求者继续执行操作
2**成功,操作被成功接收并处理
3**重定向,需要进一步的操作以完成请求
4**客户端错误,请求包含语法错误或无法完成请求
5**服务器错误,服务器在处理请求的过程中发生了错误
状态码状态码描述中文描述
200OK请求成功。一般用于GET与POST请求
301Moved Permanently永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI
302Found临时移动。资源只是临时被移动,客户端应继续使用原有URI
304Not Modified未修改。所请求的资源未修改,客户端会访问本地缓存资源
400Bad Request客户端请求的语法错误,服务器无法理解
401Unauthorized请求要求用户的身份认证
403Forbidden服务器理解请求客户端的请求,但是拒绝执行此请求
404Not Found服务器无法根据客户端的请求找到资源
500Internal Error服务器内部错误,无法完成请求
501Not Implemented服务器不支持请求的功能,无法完成请求
502Bad Gateway网关或代理服务器尝试执行请求时,从远程服务器接收到了无效的响应
503Service Unavailable由于超载或系统维护,服务器暂时的无法处理客户端的请求
504Gateway Time-out充当网关或代理的服务器,未及时从远端服务器获取请求

网络五层模型

  • 物理层(物理连通)
  • 链接层(同一网段的主机点对点通讯,MAC 地址、数据帧格式、广播)
  • 网络层(网络路由,跨网段通讯,IP 协议、ARP 协议(根据 IP 地址获取物理地址))
  • 传输层(建立端口到端口的通讯,TCP 协议、UDP 协议)
  • 应用层(HTTP 协议)

TCP 和 UDP 区别

  • TCP 是面向连接的,UDP 是无连接的
  • TCP 是可靠的,UDP 是不可靠的
  • TCP 是流式的(可以在传输层进行分片),UDP 是以包为单位来传输的(只能在IP层分片)

应用场景

  • TCP 应用场景:FTP、HTTP
  • UDP 应用场景:DNS、音视频通讯

TCP 的 KeepAlive 和 HTTP 的 KeepAlive

  • KeepAlive 并不是 TCP 协议规范的一部分,但在几乎所有的TCP/IP协议栈中都实现了该功能。TCP 的 KeepAlive 是由操作系统内核来控制,通过 keep-alive 报文来防止 TCP 连接被对端、防火墙或其他中间设备意外中断
  • HTTP 的 KeepAlive 机制是和业务密切相关的,浏览器通过头部告知服务器要复用这个 TCP 连接,只有到了 keepalive 头部规定的 timeout 才会关闭该 TCP 连接,不过这具体依赖应用服务器,应用服务器也可以根据自己的设置在响应后主动关闭这个 TCP 连接,只要在响应的时候携带 Connection: Close 告知对方

TCP 三次握手

  • 面试官:请描述一下三次握手的过程吧  
  • 求职者:第一次客户端给服务端发送一个报文,第二次是服务器收到包之后,也给客户端应答一个报文,第三次是客户端再给服务器发送一个回复报文,TCP 三次握手成功。 
  • 面试官:还有吗? 
  • 求职者:说完了哈,这就是三次握手,很简单的
  • 面试官:嗯,我没什么问的了,你还有什么问题吗?

握手的主要作用就是为了确认双方的收发能力是否正常,交换初始序列号等信息

  1. 第一次握手:客户端发送 SYN 报文,并进入 SYN_SENT 状态,等待服务器的确认
  2. 第二次握手:服务器收到 SYN 报文,需要给客户端发送 ACK 确认报文,同时服务器也要向客户端发送一个 SYN 报文,所以也就是向客户端发送 SYN + ACK 报文,此时服务器进入 SYN_RCVD 状态
  3. 第三次握手:客户端收到 SYN + ACK 报文,向服务器发送确认包,客户端进入 ESTABLISHED 状态。待服务器收到客户端发送的 ACK 包也会进入 ESTABLISHED 状态,完成三次握手

客户端由于某种原因发送了两个不同序号的 SYN 包,我们知道网络环境是复杂的,旧的数据包有可能先到达服务器。如果是两次握手,服务器收到旧的 SYN 就会立刻建立连接,那么会造成网络异常。 如果是三次握手,服务器需要回复 SYN+ACK 包,客户端会对比应答的序号,如果发现是旧的报文,就会给服务器发 RST 报文,直到正常的 SYN 到达服务器后才正常建立连接。 所以三次握手才有足够的上下文信息来判断当前连接是否是历史连接

ISN 是什么?

答:ISN 全称是 Initial Sequence Number,是 TCP 发送方的字节数据编号的原点,告诉对方我要开始发送数据的初始化序列号

ISN 是固定不变的吗?

答:ISN 如果是固定的,攻击者很容易猜出后续的确认序号,为了安全起见,避免被第三方猜到从而发送伪造的 RST 报文,因此 ISN 是动态生成的

问:三次握手过程中,可以携带数据吗?

答:第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的

TCP 四次挥手

双端都可以主动断开连接,断开连接后资源将被释放,因为有半连接状态,所以一般 FIN 和 ACK 是不会融合在一起的

主动关闭连接的,会有 TIME_WAIT 状态,时间为 2MSL(Maximum Segment Life),可以确保被动关闭一方收到最终的 ACK 消息;防止旧连接的数据包影响新建立的连接

如何解决 TIME_WAIT 过多的问题:短链转长链、keep-alive

TCP 可靠性保障

TCP 可靠性通过序列号、窗口大小、流量控制、拥塞控制、重传机制(超时重传、快速重传)实现

超时重传:超时时间应该略大于RTT(Round-trip Time),且根据网络环境动态变化

快速重传:不以时间为驱动,而是以数据来驱动,通过 SACK 确保只重传丢失的数据

滑动窗口:

流量控制:接收方根据窗口容量动态更新接收窗口

拥塞控制

  • 慢启动 & 拥塞避免

  • 超时重传 & 快速重传

IP 协议:实现主机之间的路由

最大主机个数,就是要看主机号的位数,如 C 类地址的主机号占 8 位,那么 C 类地址的最大主机个数:256 - 2 = 254,为什么要减2呢,主机号全为1指定某个网络下的所有主机,用于广播,主机号全为0指定某个网络

DNS 协议

DNS 查询顺序:本地缓存、Host 文件、本地 DNS 服务器、根 DNS 服务器、顶级 DNS 服务器(com)、权威 DNS 服务器(baidu.com)

DNS 服务器间进行域传输的时候用 TCP,客户端查询 DNS 服务器时用 UDP

ARP 协议

Address Resolution Protocol,通过 IP 地址获取 MAC 地址,如果判断当前 IP 和自己不在同一个网段,则通过 ARP 获取网关 IP 对应的 Mac 地址,否则直接获取目标 IP 对应的 Mac 地址

RARP 协议

通过 MAC 地址获取 IP 地址

ICMP(Internet Control Message Protocol)协议

ICMP 有两种报文类型,一类是「查询报文类型」,另一类是「差错报文类型」

 PING 命令就是利用 ICMP 中的查询报文来实现的

 ICMP 差错报文类型

  • 网络不可达代码为 0
  • 主机不可达代码为 1
  • 协议不可达代码为 2
  • 端口不可达代码为 3
  • 需要进行分片但设置了不分片位代码为 4

traceroute 工作原理

  • 故意设置特殊的 TTL(Time To Live),来追踪去往目的地时沿途经过的路由器
  • 故意填入一个不可能的端口号值作为 UDP 目标端口号,当差错报文类型是端口不可达时,说明发送方发出的 UDP 包到达了目的主机
  • 故意设置不分片,从而确定路径的 MTU(最大传输单元)

键入网址到网页显示,期间发生了什么

  1. 通过 DNS 协议查询域名对应的 IP 地址
  2. 解析 URL 地址,构造 HTTP 请求报文
  3. 委托链路层传输数据(TCP协议)
  4. IP 层通过 IP 路由表获取信息路由
  5. 通过 ARP 广播(Address Resolution Protocol)获取到下一跳的 Mac 地址,将 IP 数据包封装成数据帧,并设置目标 Mac 地址,并把对应数据帧广播出去

交换机

工作在链路层,自身对应多个 Mac 地址,交换机内部会维护目标 Mac 地址和端口的映射关系,内部只负责转发或者广播,通俗理解就是扩展了网络端口,可以多台设备接入物理网络

WebSocket vs Http

Http 是单向的,WebSocket 是双向的,且可以同时收发消息,高版本 Http 增加了 keep-alive 和服务端推送功能,不过还是为了解决短时间多次请求的场景

WebSocket 握手协议

  • Connection: Upgrade
    • The Connection header generally controls whether or not the network connection stays open after the current transaction finishes. A common value for this header is keep-alive to make sure the connection is persistent to allow for subsequent requests to the same server. During the WebSocket opening handshake we set to header to Upgrade, signaling that we want to keep the connection alive, and use it for non-HTTP requests.
  • Upgrade: websocket
    • The Upgrade header is used by clients to ask the server to switch to one of the listed protocols, in descending preference order. We specify websocket here to signal that the client wants to establish a WebSocket connection.
  • wss connects on https
  • ws connects on http
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

little-sparrow

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值