网络协议十:IPV6、流媒体等

IPV6

简介

  1. IPv6(Internet Protocol version 6),译为:网际协议第6版
    1. 用它来取代IPv4主要是为了解决IPv4地址枯竭问题,同时它也在其他方面对于IPv4有许多改进
    2. 然而长期以来IPv4在互联网流量中仍占据主要地位,IPv6的使用增长缓慢
    3. 在2019年12月,通过IPv6使用Google服务的用户百分率首次超过30%
      1. 因为需要设备、操作系统内核升级支持IPv6
  2. IPv6采用128位的地址,而IPv4使用的是32位
    1. 支持2的128次方(约3.4 ∗ 10的38次方)个地址
    2. 就以地球人口70亿人计算,每人平均可分得约4.86 ∗ 10 28个IPv6地址

IPv6地址格式

  1. IPv6地址为128bit,每16bit一组,共8组
  2. 每组以冒号“:”隔开,每组以4位十六进制方式表示
    1. 例如2001:0db8:86a3:08d3:1319:8a2e:0370:7344
  3. 类似于IPv4的点分十进制,同样也存在点分十六进制的写法
    1. 2.0.0.1.0.d.b.8.8.5.a.3.0.8.d.3.1.3.1.9.8.a.2.e.0.3.7.0.7.3.4.4
  4. 每组前面连续的0可以省略。下面的IPv6地址是等价的
    1. 2001:0db8:02de:0000:0000:0000:0000:0e13
    2. 2001:db8:2de:0:0:0:0:e13
  5. 可以用双冒号“::”表示一组0或多组连续的0,但只能出现一次。下面的IPv6地址是等价的
    1. 2001:db8:2de:0:0:0:0:e13
    2. 2001:db8:2de::e13
  6. 2001::25de::cade是非法的,因为双冒号出现了两次,会造成歧义
    1. 2001:0000:0000:0000:0000:25de:0000:cade
    2. 2001:0000:25de:0000:0000:0000:0000:cade
  7. ::1是本地环回地址(0:0:0:0:0:0:0:1)

首部格式

  1. 有40字节的固定首部 图1
  2. IVV4与IPV6的区别 图1
  3. 常见的字段
    1. Version(占4bit,0110):版本号
    2. Traffic Class(占8bit):交通类别
      1. 指示数据包的类别或优先级,可以帮助路由器根据数据包的优先级处理流量
      2. 如果路由器发生拥塞,则优先级最低的数据包将被丢弃
    3. Payload Length(占16bit):有效负载长度
      1. 最大值65535字节
      2. 包括了扩展头部、上层(传输层)数据的长度
    4. Hop Limit(占8bit):跳数限制
      1. 与IPv4数据包中的TTL相同
    5. Source Address(占128bit):源IPv6地址
    6. Destination Address(占128bit):目的IPv6地址
    7. Flow Label(占20bit):流标签
      1. 指示数据包属于哪个特定序列(流)
      2. 用数据包的源地址、目的地址、流标签标识一个流
  4. 扩展头部
    1. Next Header(占8bit):下一个头部
      1. 指示扩展头部(如果存在)的类型、上层数据包的协议类型(例如TCP、UDP、ICMPv6)

HTTP缓存(Cache)

  1. 缓存通常使用的场景: GET请求 + 静态资源(比如HTML、CSS、JS、图片等)
  2. ctrl+F5:可以强制刷新缓存
  3. 客户端向服务器发送请求,服务器返回响应头,那么哪些字段是用来表示缓存的呢? 请求头中哪些字段用来表示缓存的呢?

缓存-响应头

  1. Pragma:作用类似于Cache-Control,HTTP/1.0的产物(1.1已经被淘汰)
  2. Expires:缓存的过期时间(GMT格式时间),HTTP/1.0的产物(1.1已经被淘汰)
    1. 只要缓存过了这个响应头的时间,就会过期
  3. Cache-Control:设置缓存策略
    1. no-storage:告诉客户端不缓存数据到本地
    2. public:允许用户、代理服务器缓存数据到本地
      1. 客户端发送到服务器请求时,中间可能进过很多代理服务器
    3. private: 只允许用户缓存数据到本地
    4. max-age:缓存的有效时间(多长时间不过期),单位秒
    5. no-cache:每次需要发请求给服务器询问缓存是否有变化,再来决定如何使用缓存
      1. 客户端给服务器发送请求之后,服务器返回数据给客户端,客户端将数据缓存起来。
      2. 下次发送给服务器同样的请求时,会先让服务器去比对本次请求的资源跟上次比,有没有变化,如果服务器发现没有变化,此时会返回304,没有响应体,表示自己的资源没有更新,请客户端从缓存中获取
  4. 优先级:Pragma > Cache-Control > Expires
    1. 既然Pragma、Expires、Cache-Control在1.1(向下兼容的)都能使用,那么如果同时使用就会有优先级
  5. Last-Modified:资源的最后一次修改时间
    1. 服务器告诉客户端自己的资源最后一次修改时间是什么时候
  6. ETag:资源的唯一标识(根据文件内容计算出来的摘要值)单向散列函数值
  7. 优先级:ETag > Last-Modified

缓存-请求头

  1. If-None-Match
    1. 如果上一次的响应头中有ETag,就会将ETag的值作为请求头的值
    2. 如果服务器发现资源的最新摘要值跟If-None-Match不匹配,就会返回新的资源(200 OK)
    3. 否则,就不会返回资源的具体数据(304 Not Modified)
  2. If-Modified-Since
    1. 如果上一次的响应头中没有ETag,有Last-Modified,就会将Last-Modified的值作为请求头的值
    2. 如果服务器发现资源的最后一次修改时间晚于If-Modified-Since,就会返回新的资源(200 OK)
    3. 否则,就不会返回资源的具体数据(304 Not Modified)

缓存-Last-Modified vs ETag

  1. 疑问:
    1. 既然Last-Modified与ETag都能表示服务器的资源是否做了更新,那么为甚还要用两个表达呢?
  2. Last-Modified的缺陷
    1. 只能精确到秒级别,如果资源在1秒内被修改了,客户端将无法获取最新的资源数据
    2. 如果某些资源被修改了(最后一次修改时间发生了变化),但是内容并没有任何变化
      1. 会导致相同数据重复传输,没有使用到缓存
  3. ETag可以办到
    1. 只要资源的内容没有变化,就不会重复传输资源数据
    2. 只要资源的内容发生了变化,就会返回最新的资源数据给客户端

缓存使用流程

图1

即时通信、流媒体

即时通信

  1. 即时通信(Instant Messaging,简称IM),平时用的QQ、微信,都属于典型的IM应用
  2. 国内的IM开发者社区
    1. http://www.52im.net/
  3. IM云服务
    1. 网易云信、腾讯云、环信等
  4. 常用的协议
    1. XMPP、MQTT、自定义协议

XMPP

  1. XMPP(Extensible Messaging and Presence Protocol)
    1. 译为:可扩展消息与存在协议,前身是Jabber
    2. 基于TCP,默认端口5222、5269
  2. 特点
    1. 使用XML格式进行传输,体积较大
    2. 比较成熟的IM协议,开发者接入方便

MQTT

  1. MQTT(Message Queuing Telemetry Transport),译为:消息队列遥测传输
    1. 基于TCP,默认端口1883、8883(带SSL/TLS)
  2. 特点
    1. 开销很小,以降低网络流量,信息冗余远小于XMPP
    2. 不是专门为IM设计的协议,很多功能需要自己实现
    3. 很多人认为MQTT是最适合物联网(IoT,Internet of Things)的网络协议

流媒体

  1. 流媒体(Streaming Media),又叫流式媒体
    1. 是指将一连串的多媒体数据压缩后,经过互联网分段发送数据,在互联网上即时传输影音以供观赏的一种技术
    2. 此技术使得资料数据包得以像流水一样发送,不使用此技术,就必须在使用前下载整个媒体文件
  2. 常见协议
    1. RTP(Real-Time Transport Protocol),译为:实时传输协议
      1. 参考:RFC 3550RFC 3551,基于UDP
    2. RTCP(Real-Time Transport Control Protocol),译为:实时传输控制协议
      1. 参考:RFC 3550,基于UDP,使用RTP的下一个端口
    3. RTSP(Real-Time Streaming Protocol),译为:实时流协议,参考:RFC 7820
      1. 基于TCP、UDP的554端口
    4. RTMP(Real-Time Messaging Protocol),译为:实时消息传输协议,由Adobe公司出品
      1. 默认基于TCP的1935端口
    5. HLS(HTTP Live Streaming),基于HTTP的流媒体网络传输协议,苹果公司出品,参考:RFC 8216
Table of Contents