网络协议笔记(二)

发表于

目录

1. 应用层协议: DNS & DHCP

  • 应用层常见协议

    超文本协议: HTTP HTTPS

    文件传输: FTP

    电子邮件: SMTP POP3 IMAP

    动态主机配置: DHCP

    域名系统: DNS

1.1 DNS

  • 域名,Domain Name

    • IP地址不方便记忆,且无法表达组织的名称和性质,因此设计了域名
    • 访问到具体的主机,还是要知道目标主机的IP地址

    • 域名可以分为:

      1. 顶级域名,TLD,top-level Domain
2. 二级域名
3. 三级域名

  • 顶级域名

    • 通用顶级域名.General Top-level Domain,gTLD

      1. .com(公司) .org(组织机构) .edu(教育) .gov(政府部分) .int(国际组织)

    • 国家及地区顶级域名,Country Code Top-level Domain,ccTLD

      1. .cn(中国) .jp(日本) .uk(英国)

    • 新通用顶级域名,New Generic Top-level Domain, New gTLD

      1. .vip .club .shop等

  • 二级域名

    • 顶级域名之下的域名

      1. 通用顶级域名之下,一般是指名称,例如Google,baidu
2. 在国家地区顶级域名下,一般指注册类别的,例如com,edu,gov

  • DNS

    • Domain Name System,域名系统
    • 利用DNS协议,可以将域名,解析成对应的IP地址

    • DNS可以基于UDP协议,也可以基于TCP协议,服务器占用53端口

    • 服务器

      1. 客户端会先访问最近的一台DNS服务器(客户端配置的DNS服务器)
2. 所有的DNS服务器都记录了DNS根域名服务器的IP地址
3. 上级DNS服务器会记录下一级DNS服务器的IP地址
1.2 DHCP

  • IP地址按照分配方式可分为

    • 静态IP地址

      1. 手动设置
2. 使用于较为固定的台式机和服务器

    • 动态IP地址

      1. 从DHCP服务器自动获取IP地址
2. 适用场景: 移动设备和无线设备

  • DHCP

* Dynamic Host Configuration Protocol,**动态主机配置协议**
* **基于UDP协议,客户端端是68端口,服务器是67端口**
* 路由器担当了DHCP服务器的职责
* _**分配IP的4个阶段**_

        1. DISCOVER: 发现服务器;
            1.1 发广播包,源IP是0.0.0.0,目标IP是255.255.255.255,目标MAC是FF:FF:FF:FF:FF:FF)
        2. OFFER: 提供租约
            2.1 服务器返回可租用的IP地址,租用期限,子网掩码,网关,DNS等
            2.2 可能会有多个服务器提供租约
        3. REQUEST: 选择IP地址
            3.1 客户端选择一个OFFER,发送广播包回应
        4. ACKNOWLEDGE: 确认
            4.1 别选中的服务器发送ACK数据包给客户端,IP分配结束

* 可以借助DHCP中继代理,实现跨网段分配IP地址
* 客户端会在租期不足时,**自动向DHCP服务器发送REQUEST信息,申请续约**

2. HTTP

2.1 版本

  • HTTP: 超文本传输协议

    1. 应用最广泛的应用层协议之一
2. 设计的最初目的是: 提供发布和接收HTML页面的方法

  • 版本

    • HTTP/0.9, 1991年

      只支持GET请求方法获取文本数据(HTML数据),不支持请求头和响应头

    • HTTP/1.0, 1996年

      支持POST,HEAD等请求方式,支持请求头和响应头,更多的数据类型

      浏览器每次请求都需要和服务器建立一个TCP连接,请求处理完成后立即断开TCP连接

    • HTTP/1.1, 1997年

      支持PUT,DELETE等请求方法

      采用持久连接,Connec:keep-alive;多个请求可以共用一个TCP连接

    • HTTP/2.0, 2015年

    • HTTP/3.0, 2018年

  • 标准

    • 一系列的RFC(request for comments,请求意见稿)
2.2 报文格式

  • 定义的语言: ABNF,最严谨的HTTP报文格式描述形式
2.3 请求方式
  • 目前有9种请求方法
    • GET
    • HEAD
    • POST
    • PUT
    • DELETE
    • CONNECT
    • OPTIONS
    • TRACE
    • PATCH
请求方法 用途
GET 常用于读取操作,请求参数拼接在URL的后面,但是浏览器是有URL的长度限制
POST 常用于添加,修改,删除操作,请求参数可以放到请求体里,(无大小限制)
HEAD 1. 请求得到与GET请求相同的响应,但是没有响应体
2. 使用场景: 下载大文件前,先获取其大小,再决定是否要下载,以此可节约带宽资源
OPTIONS 1. 用于获取目的资源支持的通信选项,比如服务器支持的请求方法
2. HTTP/1.1, 开始支持
PUT 用于对已存在的资源进行整体覆盖
PATCH 用于对资源进行部分修改,如果资源不存在,会创建新的资源
TRACE 请求服务器回显其收到的请求信息,主要用于HTTP请求的测试和诊断
CONNECT 1. 用于开启一个客户端与所请求资源之间的双向沟通的通道,用于创建隧道tunnel
2. 可以用来访问采用了SSL(HTTPS)协议的站点
2.4 头部字段

  • 头部字段

    • 请求头字段

      有关要获取的资源或客户端本身信息的消息头

    • 响应头字段

      有关响应的补充信息,比如服务器本身的名称和版本的消息头

    • 实体头字段

      有关实体主体的更多消息,比如content-length,contrnt-type(MIME类型)

    • 通用头字段

      适用于请求和响应消息,与消息主体无关

  • 请求头字段


1. Accept-Charset中的q表示权重或者优先级,q值越大(默认和最大值是1)优先级越高

  • 响应头字段


    • Access-Control-Allow-Origin (前后端)使用解析

      1. 客户端端请求后台服务器(Tomcat),需要访问index.html资源
2. 后台服务器返回页面服务器(Nginx)地址,通过Access-Control-Allow-Origin字段
3. 返回字段例如 xxxxhost:63342,客户端去页面服务器请求index.html的数据

    • Set-cookie: 登录使用解析

      1. 登录操作,客户端会将username&password传递给服务器
2. 服务器校验通过后会生成一个session和对应的sessionid;并将sessionid放在Set-Cookie字段里返回
3. 在下一次客户端请求中客户端请求头里增加Cookie字段,服务端回去字段中取出对应的sessionid

      案例1

      案例2

2.5 状态码

  • 分类

    1. 信息响应: 100-199
2. 成功响应: 200-299
3. 重定向: 300-399
4. 客户端错误: 400-499
5. 服务器错误: 500-599

  • 常见状态码解析

    |状态码|解析|
    |:–|:–|
    |100 Continue|1. 请求的初始部分已被服务器收到,且没有被拒绝;客户端应该继续发送剩余请求,如果请求已完成,忽略
    2. 允许客户端发送带请求体的请求前,判断服务器是否愿意接受请求 |
    |200 OK|请求成功|
    |302 Found|请求的资源被暂时移动到由Location头部指定的URL上|
    |304 Not Modified|可以使用缓存内容|
    |400 Bad Request|语法无效,服务器无法处理请求|
    |401 Unauthorized|缺乏目标资源的身份验证凭证|
    |403 Forbidden|服务器有能力处理该请求,但是拒绝授权访问|
    |404 Not Found|服务器无法找到请求的资源|
    |405 Method Not Allowed|服务器净值当前HTTP方法的请求|
    |408 Request Timeout|服务器想要将未在使用的连接关闭|
    |500 Internal Server Error|所请求的服务器遇到域外情况并阻止执行请求|
    |501 Not Implemented|请求方法服务器不支持|
    |502 Bad Gateway|作为网关或代理角色的服务器,从上游服务器接收到的响应是无效的|
    |503 Server Unavailable|服务器尚未处于可以接受请求的状态|

2.6 代理服务器
  • 本身不生产内容,转发上下游的请求和响应

  • 正向代理: 代理的对象是客户端

    1. 隐藏客户端身份
2. 绕过防火墙,突破访问限制
3. 数据过滤

  • 反向代理: 代理的对象是服务器

    1. 隐藏服务器身份
2. 安全防护
3. 负载均衡

  • 抓包工具

    • 正向代理: 在客户端启动了正向代理服务

      比如Fiddler & Charles等抓包工具

    • 底层驱动: 拦截网卡处理的数据

      Wireshark的原理

  • 相关头部字段

    • Via: 追加经过的每一台代理服务器的主机名
    • X-Forwarded-For: 追加请求方的IP地址

    • X-Real_IP: 客户端的真实IP地址

2.7 CDN

  • CDN: Content Delivery/Distribution Network; 内容分发网络

    • 利用最近的服务器
    • 更快更可靠的的将资源文件传递给用户

  • 使用

    1. 用户发起请求
2. DNS解析,根据IP地理位置,接入网类型,找到离用户路由最短,负载最小的存储服务器
3. 获得缓存服务器的IP
4. 缓存服务器有目标资源,将内容返回
5. 缓存服务器无目标资源,向源站请求数据,回去数据缓存,并把内容返回给用户
2.8 Cache
  • 通常会缓存的使用场景: GET请求+静态资源

  • 响应头

    |响应头参数|内容|
    |:–|:–|
    |Pragma| 作用类似于Cache-Control, HTTP1.0|
    |Expires|缓存过期时间, HTTP1.0|
    |Cache-Control|设置缓存策略
    1. no-storage: 不缓存
    2. public,允许用户,代理服务器缓存数据到本地
    3. private: 只允许用户缓存数据到本地
    4. max-age: 缓存有效时间,单位秒
    5. no-cache: 每次需要请求服务器询问缓存是否有变更,再决定如何使用缓存|
    |Last-modified|资源最后一次修改时间|
    |ETag|资源唯一标识,文件内容计算出来的摘要值|

    优先级: Pragma > Cache-Control > Expires

    优先级: ETag > Last-modified

  • 请求头

    • if-none-match
        1. 如果上一次响应中有ETag,会将ETag作为请求头的值
        2. 如果服务器发现最新资源的摘要值和if-none-match不匹配,就返回新的资源, 状态码返回200
        3. 如果匹配,就不返回资源的具体数据,状态码返回 304

* _if-modified-since_

        1. 如果上一次响应中没有ETag,有Last-modified的值,会将Last-modified的值作为请求头
        2. 如果服务器发现资源最后一次修改时间晚于if-modified-since,就会返回新的资源,状态码为 200
        3. 否则就不返回资源的具体数据,状态码返回 304

  • Last-modified & ETag

    • Last-modified的缺陷

      • 只能精确到秒级
      • 如果资源被修改了,但是内容没有变更,还是会传输数据,造成浪费

    • ETag

      • 只要内容没有变更,就不会重复传输

  • 缓存流程

3. 网络安全

  • 面临4种安全威胁

    • 主动攻击

      中断,篡改,伪造

    • 被动攻击

      截获

  • HTTP默认使用明文传输,因此可能会有很大的安全隐患: (需要对通信内容加密)

  • 常见加密方式

    • 不可逆
      • 单向散列函数: MD5, SHA
    • 可逆
      • 对称加密: DES,3DES,AES
      • 非对称加密: RSA
    • 其它
      • 混合密码系统
      • 签名
      • 证书
3.1 网络层安全威胁

  • ARP欺骗

    • 效果

      1. 攻击者获取局域网上的数据包
2. 可让特定网络之间无法通信
3. 让送至特定IP地址的流量被错误送到攻击者所取代的地方

    • 步骤:

      • 攻击者,收到过被攻击者的ARP请求,知道被攻击者的MAC地址

      • 发送错误MAC地址的ARP响应,已达到窃听或者篡改目的

    • 防护:

      • DHCP Snooping
      • 软件监听ARP的不正常变动
3.2 传输层安全威胁

  • DoS,DDoS

    • DoS: Denial-of-Service attack,拒绝服务攻击

      1. 使目标网络或系统资源被耗尽,使服务中断或停止,其余用户无法访问
      • 带宽消耗性: UDP洪水攻击, ICMP洪水攻击
      • 资源消耗性: SYN洪水攻击, LAND洪水攻击

    • DDoS: 分布式拒绝服务攻击,Distributed Denial-of-Service attack

      1. 攻击者利用网络上对个被攻陷的电脑(僵尸)向特定目标发送DoS攻击

    • 防御

      • 入侵检测,流量过滤,多重验证: 过滤堵塞带宽的流量
      • 防火墙: 设置规则,允许或拒绝特定网络协议,端口,IP地址
        • 复杂攻击难以用简单规则阻止
      • 交换机和路由器,有一定的速度限制和访问控制能力
      • 黑洞引导
        • 将受到攻击的计算机的通信发送至一个黑洞(空接口或不存在的地址),以避免网络受到较大影响
      • 流量清洗
        • DDoS防护清洗中心,将正常流量和恶意流量区分开

  • SYN洪水攻击

    • SYN flooding attack
    • 攻击者发送一些列SYN请求到目标地址,但是让目标无法送到返回的ACK(第三次握手),而进行等待,消耗资源

    • 方法

      1. 跳过发送最后的ACK消息
2. 修改源IP地址,让目标发送SYN-ACK到伪造的IP地址,因此目标永不可能收到ACK(第3次握手)

  • LAND攻击

    • 局域网拒绝服务攻击,local area network denial attack
    • 持续发送相同的源地址和目标地址的欺骗数据包,使目标试图建立连接,消耗系统资源直至崩溃
3.3 应用层安全威胁

  • DNS劫持,域名劫持

    1. 攻击者篡改某个域名的解析结果,使得指向域名的IP地址换成另一个IP地址
2. 使得响应网址的访问被劫持到另一个不可达的或假冒地址
3. 从而实现获取用户信息等目的

  • 防护: 使用安全的DNS服务器

  • HTTP劫持: 对HTTP数据包进行拦截处理,插入JS代码
3.4 加密方式:不可逆加密-单向散列函数

  • One-way hash function

  • 称呼

    • 消息摘要函数(message digest function)
    • 哈希函数(hash function)
  • 输出散列值: 消息摘要(message digest) or 指纹(fingerprint)
  • 可以根据消息内容计算出散列值
  • 散列值的长度和消息内容的长度无关

  • 单向散列函数都会计算出固定长度的散列值

  • 特点

    1. 固定的长度的散列值
    1. 消息不同,内容不同,散列值不同(即使1bit的改变)
    1. 具有单向性(根据散列值无法计算出消息内容)

  • 常见单向散列函数

    • MD4,MD5

      产生128bit的散列值

    • SHA-1

      产生160bit的散列值

    • SHA-2

      SHA-256,SHA-384,SHA-512, 散列值分别为256位,384位,512位

    • SHA-3

      全新标准

  • 防止数据被篡改

    • 使用场景: 软件下载

      1. 将软件资源放在镜像站点,下载软件的同时获取软件版本信息等对应的散列值
2. 从源站获取一次版本信息的散列值
3. 通过对散列值比较得出软件的完整性

3.5 加密方式:可逆加密
3.5.1 对称加密
  • 加密的密钥和解密密钥一致
  • Symmetric Cryptography

  • 常见算法: DES,3DES,AES

  • DES

    • data encryption standard
    • 将64位明文加密成64位密文的对称加密算法
    • 密钥长度是64bit,但是每隔7位会有个错误检查位,因此密钥实质是56bit
    • 只能加密64bit的数据,如果遇到较大的数据,需要迭代DES加密

  • 3DES

    • 对DES重复3次所得到的一种密码算法,也叫3重DES
    • 不是三次DES加密
    • 而是加密->解密->加密的过程
    • 处理速度不高

  • AES

    • Advanced Encryption Standard
    • 取代DES成为新标准的一种加密算法,又叫做Rijndeal加密法
    • AES的密钥长度为128,92,256三种
    • 首选的对称加密算法

  • 密钥配送问题

    • 对称加密,一定会有遇到密钥配送问题
    • 解决方案
      • 事先共享密钥
      • 密钥分配中心,key distribution center,KDC
      • 非对称加密
3.5.2 非对称加密

  • 加密和解密用的密钥不同,公钥和私钥(也成为加密密钥,解密密钥)

  • 公钥&私钥

    • 一对公钥和私钥成为密钥对,key pair
    • 公钥加密的密文,需要使用对应的私钥才能解密
    • 私钥加密的密文,需要对应的公钥才能解密

  • 解决密钥配送问题

    1. 消息接收者,生成一对公钥私钥
2. 公钥发给消息的发送者
3. 消息的发送者使用公钥加密消息
4. 非对称加密的加密速度比对称加密要慢

  • RSA

    • 使用最广泛的非对称加密算法
3.6 加密方式:混合密码系统
  • Hybrid Cryptosystem
  • 对称加密的缺点: 不能很好解决密钥配送问题
  • 非对称加密的缺点: 加密解密速度慢

  • 混合密码系统

    • 将对称加密和非对称加密优势结合
    • 解决非对称加密速度慢问题
    • 解决对称加密的密钥配送问题

  • 应用场景

    • SSL /TLS

  • 加密过程

    • 会话密钥

      • 为本次通信生成的临时密钥
      • 对称密钥
      • 加密消息,提高加密解密速度

    • 步骤

      • 消息发送者拥有消息接收者的公钥
      • 生成会话密钥,作为对称加密的密钥,加密消息
      • 用公钥,加密会话密钥

      • 将会话密钥和加密的消息,一起发送给接收者

  • 解密过程

    • 用私钥解密出会话密钥
    • 再用会话密钥解密对称加密部分
![](https://forbloghexo-1258063746.cos.ap-guangzhou.myqcloud.com/%E7%BD%91%E7%BB%9C%E5%8D%8F%E8%AE%AE/Xnip2021-02-27_22-22-07.jpg)
3.7 加密方式:数字签名
  • 生成签名
    • 消息发送者完成,通过签名密钥生成
  • 验证签名
    • 消息接收者完成.通过验证密钥验证

  • 由消息发送者的私钥进行签名

  • 步骤

* 如果有人篡改消息或签名内容
    * 散列值验证失败,证明内容被篡改
  • 目的: 为了识别内容是否被篡改,并不是为了机密性

  • 作用

    1. 确认消息的完整性
    1. 识别消息是否被篡改
    1. 防止消息发送人否认

  • 在数字签名中,任何人都可以通过公钥验证签名,只有发送者能用私钥签名

  • 和非对称加密区别

3.8 加密方式:证书

  • 公钥可能会被中间人攻击

  • 公钥的合法性验证: 证书

  • 公钥证书,PKC,Public-key Certificate
    • 内含: 姓名,邮箱,以及公钥信息等信息
    • 由认证机构(CA)进行数字签名
    • 各大CA的公钥,已经默认内置在浏览器和操作系统中

4. HTTPS

4.1 简介
  • HTTPS,HyperText Transfer Protocol Secure,超文本传输安全协议

  • 也被成为:

    HTTP over TLS; HTTP over SSL; HTTP Secure

  • 默认端口: 443
  • HTTP + SSL/TLS = HTTPS

  • SSL/TLS也可以用在其它协议上

    1. FTP + SSL/TLS -> FTPS
2. SMTP + SSL/TLS -> SMTPS

  • TLS: Transport Layer Security,传输层安全性协议

    • 前身是SSL(Secure Sockets Layer),安全套接字

  • 历史版本信息

    1. SSL2.0: 1995年,2011年弃用
2. SSL3.0: 1996年,2015年被弃用
3. TLS1.2: 2008年
4. TLS1.3: 2018年

  • 原理

  • OpenSSL

    • 是SSL/TLS的开源实现
    • 可以自建一套自己的CA,自己给自己颁发证书(自签名证书)

  • 成本

    • 证书费用
    • 加解密计算
    • 访问速度降低
4.2 连接过程

  • 通信过程

    • TCP3次握手
    • TLS的连接

    • HTTP请求和响应

4.2.1 连接过程

  • 大概分为10部

  • 步骤1: Client Hello

    • TLS版本
    • 支持的加密组件(Cipher Suite)列表: 是指所用的加密算法和密钥长度

    • 一个随机数ClientRandom

  • 步骤2: Server Hello

    • TLS版本
    • 选择的Client提供的加密组件

    • 一个随机数ServerRandom

  • 步骤3: Certificate

    • 服务器的公钥证书(CA数字签名过)

  • 步骤4: Server Key Exchange

    • 用以实现ECDHE算法的一个参数(Server Params)
    • ECDHE: 一种密钥交换算法

    • Server Params,进过了服务器私钥签名

  • 步骤5: Server Hello Done

    • 告知客户端: 协商部分结束

    • 截至目前,明文共享了3个参数

      Client Random; Server Random; Server Params

    • 客户端获取到了服务器的公钥证书

  • 步骤6: Client Key Exchange

    • 用以实现ECDHE算法的一个参数(Client Params)

    • client&server都可以

      使用ECDHE算法,根据Server Params, Client Params计算出一个新的随机密钥串(Pre-Master secret)

      结合Client Params,Server Params,Pre-Master secret生成一个主密钥

      最后利用主密钥衍生出其它密钥: 客户端发送用的会话密钥,服务端发送的会话密钥

  • 步骤7: Change Cipher Spec

    • 告知服务器: 之后的通信会采用计算出来的会话密钥进行加密

  • 步骤8: Finished

    • 全部报文的整体校验值(摘要),加密之后发送给服务器

    • 这次握手是否成功,要以服务器是否能够正确解密该报文作为判断标准

  • 步骤9: Change Cipher Spec

  • 步骤10: Finished

    • 客户端服务器都验证了加密解密都没问题,握手正式结束

    • 后面开始传输加密的HTTP请求和响应

5.HTTP的升级改进

5.1 HTTP/1.1的不足

  • 不足

    • 同一时间,一个连接只能对应一个请求

      大多数浏览器支持多个并发连接

    • 只允许客户端主动发起请求

      一个请求对应一个响应

    • 头部信息重复

      为每个请求增加开销

      如果使用cookie,头部信息占用达到上千字节

  • 解决方案: SPDY

    • SPDY(speedy),基于TCP的应用层协议,强制使用SSL/TLS
    • 并不是取代HTTP,只是修改了HTTP请求相应的传输方式,传输层和网络层还是分别基于TCP/IP

    • 是HTTP/2的前身(2015年,Google不支持SPDY,拥抱HTTP/2)

5.2 HTTP/2的改进
  • 2015年正式发布

  • 在底层传输做了改造和优化,但是语意上与1.1版本兼容

    1. 想要升级至HTTP/2,开发者不需要修改代码
2. 只需要升级服务器配置,升级浏览器即可

  • 概念

    • 数据流: 已建立连接内的双向字节流,可以承载一条或多条消息

      通信都在一个TCP连接上完成,这个连接可承载任意数量的双向数据流

    • 消息: 在HTTP/2中由一系列帧组成

    • 帧: HTTP/2通信的最小单位,每一个帧都包含帧头(标示当前帧所属的数据流)

      来自不同数据流的帧可以交错发送,再根据帧头的数据流标识符重组

  • 特性

    • 二进制格式,Binary Framing

      • 二进制格式传输数据,取代HTTP/1.1的文本传输
      • 二进制格式便于解析和扩展

    • 多路复用,Multiplexing

      • 将消息分解为互不依赖的帧,交错发送,再重新组组装
      • 并行交错的发送多个请求.之间互不影响
      • 并行交错的发送多个响应.之间互不影响

      • 一个连接并行发送多个请求和响应

    • 优先级

      • 允许每一个数据流有一个关联的权重和依赖关系
      • 客户端可以构建和传递优先级树,表明如何接受响应_
      • 应先给父数据流分配资源

      • 同级数据源(相同父数据流)根据权重比例分配资源

    • 头部压缩

      • HPACK压缩请求头和响应头(减少头部开销)
      • 早期版本HTTP/2和SPDY使用zlib压缩(压缩大小减少85%-88%,但有安全问题)

      • 不同请求的相同字段被压缩

    • 服务器推送,Server Push

      • 服务器可以对一个客户端请求发送多个响应

      • 可以向客户端推送额外资源,而无需客户端明确的请求

  • 问题

    • 队头堵塞

      • TCP协议只能一个一个处理数据包,如果队头丢失某一部分,将造成对头阻塞

    • 握手延迟

      • RTT,Round Trip Time,往返延迟
5.3 HTTP/3的改进
  • Google开发,弃用TCP协议,改为基于UDP协议的QUIC协议

  • HTTP-over-QUIC,2018年改为HTTP/3

  • QUIC: 负责提供可靠传输

  • 特性

    • 连接迁移

      • TCP基于4要素(源IP,源端口,目标IP,目标端口)

        1. 切换网络时至少会有一个要素发生变化,导致连接发生变化
2. 连接发生变化时,如果还使用原有TCP连接,会导致连接失败,就需要等原连接超时重连
3. 切换新的网络或者发生网络变化时,建立新的连接仍需要几百毫秒甚至更久

      • QUIC的连接不受4要素的影响,4要素变更时,原连接扔维持

        1. QUIC连接不以4要素为标识 以一组ConnectionID(连接ID)来标识一个连接
2. 即使IP或者端口发生变化,ConnectionID没有发生变化,连接依然可以维持

  • 问题

    • 内核,CPU负载过大
      • Linux内核的UDP部分未得到像TCP部分的优化
      • TCP和TLS有硬件加速,但是对于UDP很罕见,对于QUIC更少

6.其它协议

6.1 WebSocket
  • 基于TCP,支持全双工通信的应用层协议
  • 客户端和服务器都可以主动发送消息给对方

  • 应用场景

    1. 社交
2. 股票基金报价
3. 体育实况更新
4. 多媒体聊天
5. 多玩家游戏

  • TCP本身是支持全双工通信,但是由于HTTP的请求应答模式限制TCP

  • 端口
    • port:80 ws://
    • port:443 wss://

  • 与HTTP的区别

    • 需要先建立连接,一种有状态的协议,在之后通信时可以省略部分
    • HTTP请求需要在每个请求都额外携带状态信息(如身份认证)

  • 建立连接

    • 需要借助HTTP来建立连接,Handshake

    • 客户端主动发出握手请求

      Connection: 必须设置为Upgrade,表示客户端希望连接升级

      Upgrade: websocket, 表示希望升级为WebSocket协议

      Sec-WebSocket-Version: 表示支持的websocket版本

      Sec-WebSocket-Key: 客户端生成的随机字符串

    • 服务器首页收到客户端的Sec-WebSocket-Key后

      • Sec-WebSocket-Key加上一个固定的GUID值
      • 将结果进行SHA-1摘要计算
      • 在对摘要进行HexToBase64编码
      • 将编码结果作为Sec-WebSocket-Accept的响应头的值,返回给客户端
      • 目的: 避免普通的HTTP请求被误认为WebSocket协议
6.2 WebService
  • Web服务,一种跨编程语言和跨操作系统的远程调用技术标准

  • 使用场景

    1. 天气预报,手机归属地查询,物流信息查询等
2. 物流信息,物流公司将自己地服务以WebService的形式暴露出来,让第三方调用
  • 可以用普通的Web API取代(HTTP+JSON)
  • 核心概念
    • SOAP,Simple Object Access Protocol,简单对象访问协议
    • 很多时候: SOAP = HTTP + XML
    • WebService使用SOAP协议来封装传递数据
6.3 RESTful
  • REpresentational State Transfer, 表现层状态转移
  • REST: 是一种互联网软件架构设计风格
    • 一组用于创建web服务的约束
    • 符合REST架构的Web服务,称为RESTful Web服务
  • 建议
    • URL中使用名词(复数),不使用动词
    • HTTP的方法表示动作
    • 一个资源连接到其他资源,使用子资源的形式
    • 返回JSON格式
6.4 HTTPDNS
  • 基于HTTP协议向DNS服务器发送域名解析请求
    • 替代了基于DNS协议向运营商local DNS发起解析请求的方式
    • 避免Local DNS造成的域名劫持和跨网访问问题
    • 常用在移动互联网中

6.5 FTP
  • 文件传输协议,File Transport Protocol
  • 基于TCP的应用层协议

  • 固定的URL格式

  • 连接模式: 主动active和被动passive

    • 都需要建立两个连接,控制连接和数据连接
    • 控制连接: 用于传输状态信息,命令,cmd
    • 数据连接: 用于传输文件和目录信息,data

  • 主动模式

    • 客户端打开一个随机命令端口
      • 端口号大于1024,假设为N
      • 同时连接至服务器的命令端口21

    • 客户端开始监听N+1数据端口

      • 同时向服务器发送一个port命令给服务器命令端口21

        1. 此命令告诉服务器,客户端正在监听数据端口N+1
2. 且已准备好从此端口接收数据

    • 服务器打开20数据端口,创建于客户端(N+1)端口的连接

  • 被动模式

    • 客户端的命令端口N用于服务器命令端口21
    • 客户端通过命令端口N发送PASV命令给服务器的命令端口21
    • 服务器打开一个随机端口P,并告知客户端该端口号P

    • 客户端数据端口N+1发起与服务端数据端口P的连接

6.6 邮件协议

  • 发送邮件

    • SMTP,Simple Mail Transfer Protocol,简单邮件传输协议

      1. 基于TCP
2. 服务器默认使用25端口,SSL/TLS使用465端口

  • 接收邮件

    • POP, Post Office Protocol

      1. 基于TCP
2. 最新版本是POP3
3. 服务器默认使用110端口,SSL/TLS使用995端口

    • IMAP, Internet Message Access Protocol,信息访问协议

      1. 基于TCP
2. 服务器默认使用143端口,SSL/TLS使用993端口

  • POP和IMAP区别

    • POP

      • 客户端连接服务器时,会从服务器下载所有邮件
      • 客户端的操作(删除邮件,移动文件夹等)_不会_和服务器同步
      • 每个客户端都是独立的,都可以获得自己的电子邮件副本

    • IMAP

      • 客户端连接服务器时,获取的是服务器上邮件的基本信息,并不会下载邮件(具体打开邮件时,才开始下载邮件)
      • 客户端的操作(删除邮件,移动文件夹等)_会_和服务器同步
      • 所有客户端始终会看到相同的邮件和相同的文件夹
6.7 IPv6
  • IPv4: 32位地址

  • IPv6: 128位地址

  • 地址格式

    • 128位,每16位一组,共8组
    • 每组以冒号相隔,每组以4位16进制方式表示
    • 也可以使用点分十六进制

    • 每组前面连续的0可以省略

      1. 2001:0db8:02de:0000:0000:xxxxxx......
2. 2001:db8:2de:0:0:xxxxxx.......
3. 两者等价

    • 可以用双冒号::表示一组0或者多组连续的0,只能出现一次

      1. 2001:db8:2de:0:0:0:0:e13
2. 2001:db8:2de::e13
3. 两者等价
    • ::1本都环回地址(0:0:0:0:0:0:0:1)
  • 首部格式
![](https://forbloghexo-1258063746.cos.ap-guangzhou.myqcloud.com/%E7%BD%91%E7%BB%9C%E5%8D%8F%E8%AE%AE/Xnip2021-02-28_21-55-56.jpg)

+ 40字节固定首部
+ **Version**: 版本号
+ **Traffic Class**: 交通类别

        1. 数据包的类别和优先级,帮助路由器根据优先级处理
        2. 如果路由器发生拥塞,优先级最低的数据包会被丢弃
+ **Payload Length**: 有效负载长度

        1. 16bit
        2. 包含扩展头部,传输层数据的长度
+ **Hop Limit**: 跳数限制
    + 与IPv4中的TTL相同
+ **Source Address**: 源IPv6地址
+ **Destination Address**: 目标IPv6地址
+ **Flow Label**: 流标签

        1. 指示数据包属于哪个特定序列
        2. 源地址,目标地址和流标签标识一个数据流

+ 扩展头部: **Next Header**, 下一个头部
6.8 即时通信
  • Instant Messaging,IM
  • IM云服务: 网易云信, 腾讯云, 环信
  • 常用的协议
    • XMPP
    • MQTT
    • 自定义协议

  • XMPP

    • 可扩展消息与存在协议
    • 基于TCP
    • 默认端口是: 5222,5269
    • 特点
      • XML格式传输,体积大
      • 技术成熟

  • MQTT

    • 消息队列遥测传输
    • 基于TCP
    • 默认端口是: 1883,8883
    • 特点
      • 开销小,信息冗余小
      • 需要自己实现功能
      • 最适合物联网,loT,网络协议
6.9 流媒体

  • 流式媒体,Streaming Media

    将连续的多媒体数据压缩后,经过互联网分段发送,在互联网上计时传输影音

  • 常见协议

    • RTP,Real-Time Transport Protocol, 实时传输协议

      基于UDP

    • RTCP,Real-Time Transport Control Protocol,实时传输控制协议

      基于UDP,使用RTP的下一个端口

    • RTSP,Real-Time Streaming Protocol,实时流协议

      基于TCP,UDP的554端口

    • RTMP,Real-Time Messaging Protocol,实时消息协议

      基于TCP的1935端口

    • HLS,HTTP Live Streaming

      1. 基于HTTP的流媒体网络传输协议
      1. 苹果公司出品