网络协议——入门

网络协议就是规定设备之间通信的方式

网络协议说明

OSI七层模型：

1. 物理层
2. 数据链路层
3. 网络层
4. 传输层
5. 会话层
6. 表示层
7. 应用层

实际模型：

1. 网络接口层
2. 网际层（网络层）
3. 传输层
4. 应用层

ps: 每一层相当于是加了个信息，如 4 、43 、2432 、12432 这样从应用层到物理层，获取数据后则反过来

学术研究模型：

1. 物理层
2. 数据链路层
3. 网络层
4. 传输层
5. 应用层

计算机之间的通信基础

1. 需要知道对方IP地址
2. 最终是跟你讲MAC地址(网卡地址)，输送数据到网卡，被网卡接收
3. 如果网卡发现数据（包含：源IP、目标IP地址、源MAC地址、目标MAC地址等）的目标MAC地址是自己，就会将数据传递给上一层进行处理
4. 如果网卡发现数据（包含：源IP、目标IP地址、源MAC地址、目标MAC地址等）的目标MAC地址不是是自己，就不会将数据（数据被丢弃）传递给上一层进行处理

连接方式 —— 网线直连

1. 下载Cisco Packet Tracer.
2. 创建2个电脑，使用交叉线连接
   
   ps: 这里的端口是网线插口
3. 配置2填电脑的IP地址、子网掩码，点击主机，找到桌面选项中的IP配置
   
   

ps: 不需要保存，可以之间关闭，2台主机必须在同一网段如：192.168.10.111 和192.168.10.113就是同一网段，但192.168.11.111和192.168.10.113就不是同一网段（具体还是要看子网掩码）
4. 在命令提示符中ping 另一台机器，通过仿真模式进行查看

5.开始的时候是不知道网卡的，所以走的是ARP协议（广播：广播是在同一个网段中进行传播的），当ping过一次知道了网卡地址后，走的是ICMP协议
当目标地址是全FFFF.FFFF.FFFF表示是一个广播，用来获取目标的MAC地址的

连接方式 —— 同轴电缆

1.半双工通信：表示只能向某一端发送数据，当一端发送数据时，另一端是不能同时发送数据的，数据流只能指向一端
2. 全双工通信：两端可以同时互相发送
3. 同轴电缆是半双工通信
4. 容易冲突

5.如图，这时当二号机发送给三号机时，那么四号机是不能发送给三号机的
6.不安全（在不是目标机器可以通过抓包获取数据）

7. 如图，当二号机要发送给四号机时，数据会同时发送给冲突域中其他机器，只不过是因为MAC地址不对，机器不接收
8. 中间网断了的话，整个就瘫了，因为没有电阻进行接收数据，数据会进行返回

连接方式 —— 集线器（同轴电缆升级版）

1. 半双工通信
2. 容易冲突
3. 和同轴电缆一样，数据沿着线发送（只要有线就发送）、
4. 不安全（在不是目标机器可以通过抓包获取数据）
   
5. ip101 ping ip102
   
6. 计算机在命令提示符中可以查看arp的缓存地址

7. 可以看到，不同种类设备使用的是直通线，同种类设备使用的是交叉线

8. 使用集线器时，当设备越多，那么就越慢，应为数据会发送给所以设备

连接方式 —— 网桥

ps: 比如当pc6发送数据给pc2时，那么网桥就能获取左侧pc6的MAC和右侧pc2的MAC，当pc6发送数据给pc7时，在ARP时就能获取左侧pc7的MAC，在ICMP协议时网桥就会在发送数据给右侧

1. 可以通过自学习得知每个接口那侧的MAC地址
2. 隔绝冲突域
3. 虽然有一定作用，但是冲突域内还是不能同时发送信息

连接方式——交换机（局域网的最终方案）

1. 相当于接口更多的网桥
2. 全双工通信
3. 比集线器安全
4. 思考： 如果全球的计算机是交换机连接，那么会产生广播风暴

连接方式——路由器

网线直连、同轴电缆、集线器、网桥、交换机

• 连接的设备必须在同一网段（一般情况）
• 连接的设备处在同一广播域

路由器

• 隔绝广播域
• 可以在不同网段之间转发数据

ps: 当pc1发送ARP时，会被route1给拦截，因为网段不同

• 主机发送数据之前，首先会判断目标主机的IP地址跟它是否在同一个网段
  • 在同一个网段：发送ARP协议、通过交换机\集线器传递数据
  • 不在同一个网段：通过路由器转发数据

查看路由表

单机路由器 —> Routing Table 选项 —>查看路由表

网关（gateway）

网关可以实现跨网段的作用

修改对应的连接端口的ip和子网掩码

开启端口

把pc的默认网关改成路由器那一侧的ip地址
当pc1发数据包给pc4时
需要获取到网关的MAC地址

当网关192.168.2.1要发送数据到pc4时，
也需要获取到pc4的MAC地址，需要再次发送ARP

MAC地址

• 每一个网卡都有一个6字节（48bit）的MAC地址
  
• 全球唯一，固化在了网卡的ROM中，由IEEE802标准规定
  • 前三个字节：OUI，组织唯一标识符，由IEEE的注册管理机构分配给厂商
  • 后三个字节：网络接口标识符，由厂商自行分配

MAC地址格式

• Windows: 40-55-82-0A-8C-6D
• Linux、Android、Mac、IOS：40:55:0A:8C:6D
• Packet Tracer：4055.820A.8C6D
• 当48位全为1时，代表广播地址：FF-FF-FF-FF-FF-FF

MAC地址操作（Windows）

• 查看MAC地址： ipconfig / all
• 这里的修改指的是假的MAC地址，不是网卡中的MAC地址
• 修改MAC地址
  • 更改适配器选项 - 属性 - 配置 - 高级 - 网络地址
  • 注意：WLAN是不行的
  • 减号去掉
  • 下图中的不存在，是用的是网卡中的MAC地址
    

MAC地址的获取

可以通过发送ARP广播获取

• 获取成功后，会缓存IP地址、MAC地址的映射信息，俗称：ARP缓存
• 通过ARP广播获取的MAC地址，属于动态缓存，存储实际比较短（默认是2分钟），过期了就自动删除

相关命令

• arp -a [组件地址] : 查询ARP缓存
• arp -d [主机地址]：删除ARP缓存
• arp -s 主机地址 MAC地址：增加一条缓存信息（这是静态缓存，存储实际较久）

IP地址

IP地址介绍

• 互联网上的明媚阳光主机都有一个IP地址
• 最初是IPV4版本，32bit（4字节），2019年11月25日，全球的IP地址以及用完
• 后面退出了IPV6版本，128bit（16字节）
  

IP地址组成

• 由两部分组成：网络标识（网络ID）、主机标识（主机ID）
• 同一网段的计算机，网络ID相同
• 通过子网掩码可以计算出网络ID：子网掩码&（按位与）IP地址

  • IP：192.168.1.10 子网掩码：255.255.255.0 、
    

    • 所以如果ip地址末尾是0，则表面是一个网段

    • 其中，192.168.1是网络ID，10表示主机ID

      

IP地址的分类

• A类地址：默认子网掩码是255.0.0.0，网络ID（8bit，0开头，1~126，其中127作为保留网段，127.0.0.1是本地环回地址）,主机ID（24bit）
• B类地址：默认子网掩码是255.255.0.0，网络ID（16bit，10开头，128.0~191.255）,主机ID（16bit）
• C类地址：默认子网掩码试试255.255.255.0，网络ID（24bit，110开头，192.0.0~223.255.255）,主机ID（8bit）
• D类地址：以1110开头，多播地址，224~239
• E类地址：以1111开头，保留为今后使用，240~255
• 只有A/B/C类地址才能分配给主机
• CIDR表示方法
  • 192.168.1.100/24 ，代表子网掩码有24个1，也就是255.255.255.0
  • 123.210.100.220/16，代表子网掩码有16个1，也就是255.255.0.0

子网划分

• 子网划分：借用主机位作子网位，划分出多个子网
  • 可用分为：
    • 等长子网划分：将一个网段分出多个子网，每个子网的可用IP地址数是一样的
    • 变长子网划分：每一个子网的可用IP地址数量可用是不一样的

等长子网划分：

如

192.168.1.10和192.168.1.80是在同一网段中

192.168.1.10和192.168.1.200不在同一网段

要想ping通，添加一个路由器即可

变长子网划分：

如：
C类网段是源网段的（1/2）的一次方，那么就移1位
B类网段是源网段的（1/2）的二次方=1/4,那么就移2位,
是（1/2）的几次方就移几位
····

扩展

按上图，通过IP&子网掩码，发现网段是一样的
192.168.0.10&255.255.255.0 = 192.168.0.0/24
192.168.10.10&255.255.0.0=192.168.0.0/16
但是ping不通

因为当ping的时候，首先要确认是否在同一网段pc1只知道pc2的ip，
而不知道子网掩码，所以是pc1用自己的子网掩码&pc2的ip，计算网段
192.168.10.10&255.255.255.0=192.168.10.0
192.168.10.0与192.168.0.0不在同一网段

超网

介绍

超网：跟子网反过来，他是将多个连续的网段合并成一个更大的网段

思考

192.168.0.255/23可用分配给计算机？
可以的
192.168.0.255/24 不行，因为这时的主机地址全是1，也就是1111 1111=255
是广播地址
但192.168.0.255/23的主机地址是 0 1111 1111，不是全1，可以分配
在这个网段中的实际广播地址是：192.168.1.255/23

合并成超网规律

通过看左边就能发现192.168.1.0和192.168.2.0只移动1位是不能合并的
因为你左边是要一样才行

路由

介绍

在不同网段之间转发数据，需要有路由器的支持
默认情况下，路由器只知道跟它直连的网段，非直连的网段需要通过静态路由、动态路由告诉它

静态路由

• 管理员手动添加路由信息
• 适用于小规模网络

路由器1
网络：193.169.2.0（网段）
掩码：255.255.255.0
下一跳：路由2的sa口ip
ps：
也可以配精确的ip，但如果添加了一台新设备，
在同一个网段内又需要手动添加一次ip，同时掩码是255.255.255.255，在路由中表示精确ip

精确ip

这个是默认路由，不确定时，只要是下一天的都可以访问到

路由器2
网络：192.168.1.0（网段）
掩码：255.255.255.0
下一跳：路由1的sa口ip

当pc1要ping到pc4时
是ping不通的，路由之间也发送不了数据
可以添加静态路由
路由与路由之间直连需要在同一个网段，准确的讲是配置图中的<下一跳>必须和自己在同一网段

查看路由表

动态路由

• 路由器通过路由器选择协议（比如RIP、OSPF）自动获取路由信息
• 使用于大规模网络

网络、互联网、因特网

网络

就是一组设备之间可以互相通信

互联网

因特网

全世界最大的互联网是：因特网（Internnet）
一般大写就是指因特网，小写指互联网

ISP

介绍

ISP：Internet Service Provider，Innternet服务提供商，比如移动、电信、网通、铁通等
我们平时拉的宽带都是通过ISP连接到Interent的

服务器机房

就好比如说
当你电脑是电信的时候，你访问电信机房指需要经电信ISP就行，但你要访问移动的
那么你首先要经过电信ISP，在通过移动ISP连接到移动机房，网速肯定会慢点

网络分类

按照网络的范围进行分类，可以分为:局域网、城域网、广域网等

局域网(Local Area Network，LAN)

• 一般是范围在几百米到十几公里内的计算机所构成的计算机网络口常用于公司、家庭、学校、医院、机关、一幢大楼等
• 局域网中使用最广泛的网络技术叫:以太网(Ethernet)
• 在电脑、手机上经常见到的一个英文WLAN (wireless LAN)，意思是无线局域网

城域网(Metropolitan Area Network，MAN)

• 一般范围是数十公里到数百公里，可以覆盖一个城市

广域网(Wide Area Netword,WAN)

• 一般范围是几百公里到几千公里，可以覆盖一个国家。通常都需要租用ISP的线路。

常见的几种接口

上网方式

电话入户

光纤入户

现在比较多

网线入户

类似校园网 —>就一根网线就能上网

家用无线路由器逻辑结构

公网IP、私网IP

比如自己上网时获取的是私网IP
那么公网路由器要想发送给自己进行请求
就必须用到NAT

NAT

介绍

如图
NAT就是把私网IP转换成公网IP
下面通过百度查询的IP
是最后一次进行NAT转换后因特网获取的IP
并不是实际上的IP

因特网发数据给私网IP时
现在是通过端口记录下每个IP对应的请求

补充

• 当不同网段的pc互ping时，第一次包丢失
  
  

因为当pc1发送ARP包时，获取的是网关的MAC地址，然后发送
ICMP协议中的IP是192.168.1.11，但不是网关地址，所以
路由器另一个接口会发送ARP广播，但是从pc1发送的ICMP协议包会
被路由器给丢掉

网络分层（七层网络模型详解）

网络互连模型

请求过程

物理层

• 物理层定义了接口标准、线缆标准、传输速率、传输方式等
  

数字信号、模拟信号

• 模拟信号（Analog Signal）
  • 连续的信号，时候长距离传输
  • 抗干扰能力差，受到干扰时波形变形很难纠正
• 数字信号（Digital Signal）
  • 离散的信号，不适合长距离传输
  • 抗干扰能力强，受到干扰时波形失真可以修复

数据通信模型

信道

• 信道： 信息传输的通道，一条传输介质上（比如网线）上可以有多条信道
• 单工通信
  • 信号只能往一个方向传输，任何时候都不能改变信号的传输方向
  • 比如无线电广播，有限电视广播
• 半双工通信
  • 信号可以双向传输，但必须是交替进行，同一时间只能往一个方向传输
  • 比如对讲机
• 全双工通信
• 信号可以同时双向传输
• 比如手机（打电话）

数据链路层

• 链路：从一个节点道相邻节点的一段物理线路（有线或无线），中间没有其他交换节点
  

上图，红框圈起来的就是一条链路
计算机0到路由器0之间是一条链路，因为集线器相当于是一根网线
路由器之间传输，数据可能不一样，因为MAC不同，发送时的MAC自然改变

• 数据链路：在一条链式上传输数据时，需要有对应的通信协议来控制数据的传输
  • 不同类型的数据链路，所用的通信协议可能是不同的
    • 广播信道：CSMA/CD协议（比如同轴电缆、集线器等组成的网络）
    • 点对点信道：PPP协议（比如两个路由器之间的信道）

数据链路层的三个基本问题

封装成帧

• 帧（Frame）的数据部分
  • 就是网络层传递下的数据包（IP数据包）
• 最大传输单元MTU(Maximum Transfer Unit)
  • 每一种数据链路层协议都规定了所能够传送的帧的数据长度上限
• 以太网的MTU为1500个字节（CSMA协议）

透明传输

上图
当数据中出现EOT字符
可能会让SOH误认为数据结束了
会把后面的数据丢弃

因为ESC也是特殊字符
所以需要自己进行转义

差错检验

比如pc1发送数据到pc2
当pc1发送数据时是先将数据部分和首部进行计算得出FCS
等数据发送到pc2时，pc2也会把数据部分和首部进行计算得出FCS
当pc2的FCS和pc1发送的FCS不一样时，网卡就会把数据抛弃
为什么要进行差错检验是因为数据在传输过程中，可能因为某些原因导致数据混乱或者说数据错误

CSMA/CD协议（以太网）

• CSMA/CD (Carrier Sense Multiple Access with Collision Detectio)
  • 载波侦听多路访问/冲突检测
• 使用了CSMA/CD的网络可以称为是以太网(Ethernet)，它传输的是以太网帧
  • 以太网帧的格式有:Ethernet V2标准、IEEE的802.3标准
  • 使用最多的是: Ethernet V2标准
• 为了能够检测正在发送的帧是否产生了冲突，以太网的帧至少要64字节
• 用交换机组建的网络，已经支持全双工通信，不需要再使用CSMA/CD，但它传输的帧依然是以太网帧
  • 所以，用交换机组建的网络，依然可以叫做以太网

Ethernet V2

PPP协议（点对点协议）

网卡

• 网卡接收到一个帧，首先会进行差错校验，如果校验通过则接收，否则丢弃
• 抓包工具（Wireshark）抓到的真能没有FCS，因为它抓到的是差错校验通过的帧（帧尾的FCS会被硬件去掉）
  • Wireshark抓不到差错校验失败的帧
• 网卡其实工作在物理层和数据链路层也就是二层设备，集线器是一层设备，交换机是二层设备（现在已经有三层交换机了），路由器是三层设备

这里用的是Wireshark抓包工具进行抓包
可以看到目标MAC地址和源MAC地址
通过切换不同目标发现是没有FCS的

网络层

网络层数据包（IP数据包、Packer）

• 由首部、数据两部分组成
• 数据：一般是由传输层传递下来的数据段
  
  

注意：这里的占位指的是二进制位数

版本（Version）

• 占4位
• 0b0100：IPv4
• 0b0110：IPv6

首部长度（Header Length）

• 占4位，二进制乘以4才是最终长度
• 0b0101(5)：20(最小值)
• 0b1111(15)：60(最大值)
• 则可变长度部分最大是40

区分服务

• 占8位
• 可以用于提供网络的服务质量

总长度

• 占16位
• 首部+数据长度之和，最大值65535（字节）
• 由于帧的数据不能超过1500字节，所以过大的IP数据包需要分成片传输给数据链路层
  • 每一片都有字节的网络层首部(IP首部)
    

标识

• 占16位
• 数据包的ID，当数据包过大进行分片时，同一个数据包的所有片的标识都是一样的
• 有一个计数器专门管理数据包的ID，每发出一个数据包，ID就加1

标志

• 占3位
• 第一位：保留
• 第二位：1代表不允许分片，0代表允许分片
• 第三位：1代表不是最后一片，0代表是最后一片

片偏移

• 占13位
• 片偏移乘以8：字节偏移
• 每一片的长度一定是8的整数倍

如下图
每一片数据包最大是1440字节
因为首部最大是60字节，而每一帧不能超过1500个字节

上面三张图
第一，通过ping百度 发送的数据包800个字节
第二，发现总共是828个字节
首先，网络层首部20字节，加上数据包800字节一共是820个字节
第三，是ICMP协议的数据所占字节，刚好是8位
总的来说
ICMP协议是
就是20位首部+8位ICMP首部+800数据

这里是进行了拆片
当刚发送的时候，还不知道是ICMP协议
直到最后一片才知道是ICMP协议

生存时间（TTL）

• 占8位
• 每个路由器在转发之前会将TTL减1，一旦发现TTL减为0，路由器会返回错误报告
• 可以通过ping命令皇后的TTL，能够退出对方的操作系统，中间经过了多少个路由器

比如连接一个路由器，但这个路由器又连接其他路由器
当数据包进行发送时，那么TTL就会减一
比如说：
有2个路由器，这2个路由器的默认路由互相指向对方
A ->B B->A 
当发送一个数据包到A时，数据包的目标IP不在A的路由表中，那么A就走默认路由到B，刚好数据包的目标IP也不在B的路由表中，那么就走B的默认路由到A，这样就形成一个环形，这时有TTL就能说返回一个错误
一般来讲服务器要么是Windowws，要么是Linux，根据上图
如果是Windows的话，要经过128-52=76个路由器，太多了
所以应该是Linux 2.0.x 即 64-52=12个路由器

可以通过tracert、pathping命令，可以跟踪数据包经过了哪些路由器

协议

• 占8位
• 表明所封装的数据是使用了什么协议
  

首部校验和

• 用于检查首部是否有错误

传输层

UDP/用户数据报协议

• UDP是无连接的，减少了建立和释放连接的开销
• UDP尽最大能力交付，不保证可靠交付
  • 因此不需要维护一些复杂的参数，首部只要8个字节（TCP首部至少20个字节）
  • 1字节8bit00000000（二进制位数），1bit=二进制的1位

• UDP长度
  • 占16位，首部的长度+数据的长度
• 检验和
  • 计算内容：伪首部+首部+数据
  • 伪首部：仅在计算检验和的时候起作用，并不会传递给网络层

• 端口
  • UDP首部中端口是占用2字节，也就是取值范围是：0~65535
  • 客户端的源端口是临时开启的随机端口
  • 防火墙可以设置开启\关闭某些端口来提高安全性
  • 常用命令
    • netstat -an:查看被占用的端口
    • netstat -anb:查看被占用的端口，占用端口的应用程序
    • telnet 主机 端口：查看是否可以访问主机的某个端口
      

TCP/传输控制协议

数据格式

• 数据偏移

  • 占4位，取值范围：0x0101~0x1111
  • 乘以4：首部长度，类似网络层的首部长度，总的来说就是这二进制数乘以4的积就是整个首部的长度（固定部分+可选部分）
  • 首部长度是20~60字节

• 保留

  • 占6位，目前全为0，就保留下来，目前来说还不知道用来干嘛
  • 有些资料说TCP首部的保留字段占3位，标志位（就图中保留旁边的那些字母）占9位，但是这些标志位中的有3位是不怎么用的，也可以说是保留位（Wireshark中是这样的）

• 细节说明

  • UDP的首部中有16位的字段记录整个UDP报文长度（首部+数据），但是TCP首部中仅仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度
  • UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐
  • TCP\UDP的数据长度，完全可以由IP数据包的首部推测处理
  • 传输层的数据长度=网络层的总长度-网络层的首部长度-传输层的首部长度

• 检验和

  • 跟UDP一样，TCP检验和的计算内容：伪首部+首部+数据
  • 伪首部：占12字节，仅在计算检验和的时候起作用，并不会传递给网络层

• 标志位

  • URG
    • 当URG=1时，紧急指针字段才有效，表明当前报文段中有紧急数据，应有些尽快传送
  • ACK
    • 当ACK=1时，确认号字段才有效
  • PSH
    • 用在交互式通信网络
  • RST
    • 当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
  • SYN
    • 当SYN=1、ACK=0时，表明这是一个建立连接的请求
    • 若对方同意建立连接，则回复SYN=1、ACK=1
  • FIN
    • 当FIN=1时，表明数据以及发送完毕，要求释放连接

• 紧急指针

  • 存放一个数字，比如8的话，就表明TCP前面8个字节的数据比较重要

以下是指再建立连接后的，就是三次握手之后

• 序号
  • 占4字节
  • 首先，在传输过程中的每一个字节都会有一个编号
  • 在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号
• 确认号
  • 占4字节
  • 在建立连接之后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号
• 窗口
  • 占2字节
  • 这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）

可靠传输

可靠传输
就是当服务器向客户端发送数据时，比如发送了4个数据包
在某些原因下，如 路由器一不小心就把其中一个包丢了
那么服务器收到的只有客户端返回说收到3个包的信息
那么服务器就会再次发送丢失的那个包数据

• 停止等待ARQ协议，自动重传请求

• 连续ARQ协议+滑动窗口协议
  
  

现在假设每一组数据是100个字节，代表一个数据段的数据，注意：这里的每一个包还要加上首部
每一组给一个编号
下图中当B返回给A的ACK=1，ack=401 其中ack=401表示确认号

• SACK(选择性确认)
  • 在TCP通信过程中，人如果发送序列中间某个数据包丢失（比如1、2、3、4、5中的3丢失了）
  • TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、4、5）
  • 这样原先已经正确传输的分组也可能重复发送（比如4、5），降低了TCP性能
  • 改善的技术SACK（选择性确认）技术
    • 告诉发送方那些数据丢失，那些数据已经提前收到
    • 使TCP只重新方法是丢失的包（比如3），不用发送后续所有的分组（比如4、5）
  • SACK信息会放在TCP首部的选项部分
    • Kind：占1字节，值为5代表这是SACK选项
    • Lengthh：占1字节，表明SACK选项一共占用多少字节
    • Left Edge：占4字节，左边界
    • Right Edge：占4字节，右边界
    • 一队编辑选项需要占用8字节，由于TCP首部的选项部分最多40字节，所以
    • SACK选项最多携带4组边界信息
    • SACK选项的最大占用字节数=4*8+2=34
      
      
      
      
      

2755926066-1453=2755924614-1=同一标识，就是同一个请求
通过对比Seq和Ack就能发现
ps：
重发次数一般是看系统的设置，有些是5次或者一定的时间
如果接收窗口最多能接受4个包
但对方只发了2个包
那么就会等待一定时间后没有弟3个包就会返回确认收到2个包给对方

• 选择在传输层对数据晋宁县分段的原因
  • 可以提高重传的性能(UDP是没有重传的)
  • 可靠传输是在传输层进行控制的
  • 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都要重传
  • 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些字段即可

链接: 测试抓包地址

流量控制

如果接收方的缓存区满了，发送方还在疯狂的发送数据
接收方只能把收到的数据包丢掉，大量的丢包会极大浪费网络资源
所以需要流量控制

• 什么是流量控制
  • 让发送方的发送速率不要太快，让接收方来得及接收处理
• 原理
  • 通过确认报文中窗口字段来控制发送方的发送速率
  • 发送方的发送窗口大小不能超过接收方给出窗口大小
  • 当发送方收到窗口的大小为0时，发送方就会停止发送数据
• 特殊请求
  • 一开始，接收方给发送方发送了0窗口（就是缓存为0，窗口大小为0）的报文段
  • 后面，接收方又有了一下存储空间，给发送方发送的非0窗口的报文段丢失了
  • 发送方的发送窗口一直为0，双方陷入僵局
  • 解决方案：
    • 当发送方收到0从窗口通知时，这时发送方停止发送报文
    • 并且同时开启一共定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
    • 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器

拥塞控制

• 拥塞控制

  • 防止过多的数据注入到网络中
  • 避免网络中的路由器或链路过载

• 拥塞控制时一共全局性的过程

  • 涉及到所有的主机、路由器
  • 以及与降低网络传输性能有关的所有因素
  • 是大家共同努力的结果

• 相对而言，流量控制是点对点（端对端）的控制

• 缩写

  • MSS：每个段最大的数据部分大小
    • 在建立连接时确定
  • cwnd：拥塞窗口
    • 在发送方，会进行拥塞控制
    • 自己通过感知网络状态，自我调整大小
  • rwnd：接收窗口
  • swnd：发送窗口
    • swnd = min（cwnd，rwnd）— 就是在拥塞窗口和接收窗口中取最小值为发 送窗口

• 方法

  • 慢开始（慢启动）
    
    

    • 如上图就是2的n次方 ，每次发送
    • cwnd的初始值比较小，然后随着数据包被接收方确认（收到一共ACK）
    • cwnd就成倍增长（指数级）

  • 拥塞避免
    

    • ssthresh（slow start threshold）：慢开始阈值，cwnd达到阈值后，以线性方式增加
    • 拥塞避免（加法增大）：拥塞窗口缓慢增长，以防止网络过早出现拥塞
    • 拥塞避免（乘法减小）：只要网络出现拥塞，把ssthresh减半，于此同时，指向慢开始算法（cwnd又恢复到初始值 ）
    • 当网络出现频繁拥塞时，ssthresh值就下降的很快

  • 快速重传
    

    • 接收方：
    • 每收到一个失序的分组后就立即发出重复确认
    • 使发送方及时知道有分组没有到达
    • 而不要等待自己发送数据时才进行确认
    • 发送方：
    • 只要连续收到桑重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段
    • 而不必绩效等待重传计时器到期后再重传

  • 快速恢复

    • 快重传+快恢复
      
    • 当发送方连续收到桑1重复确认，就执行“乘法减小”算法，把ssthresh减半，这是为了语法网络发送拥塞
    • 由于发送方现在认为网络很可能没有发送拥塞
    • 因此，与慢开始不同之处时现在不执行慢开始算法，即cwnd现在不恢复到初始设
    • 而是把cwnd值设置为ssthresh减半后的数值
    • 然后开始执行拥塞避免算法（加法增大），使拥塞窗口缓慢地线性增大

  • 发送窗口的最大值
    * 发送窗口的最大值：swnd = min（cwnd，rwnd）
    * 当rwnd<cwnd时，是接收方的接收能力限制发送窗口的最大值
    * 当rwnd>cwnd是事实，则是网络的拥塞限制发送窗口的最大值

连接管理

• 建立连接
  

  这里有明显的三次握手
  第一次，客户端发送请求给服务器，SYN表示建立同步请求
  服务器返回的SYN和ACK表示同意建立
  客户端发送ACK回应同意，注意：在建立连接时是没有数据的
  就好比如：
  面试时
  我说：我今天能上班，
  老板：没问题，等下就直接上班
  我说：好的，等下我就直接上岗
  这里是不算工资的（没入职怎么打卡？）
  

  

  下面三张图相当于是对上图的说明
  

  
  
  
  

  

  

  c: 客户端
  s: 服务器
  这是上图的，主要是说明Seq和ACK的关系
  在抓包过程中的1啊，1461等等都是相对值
  原生值的话是在第一次发送请求的时候2边都发送了真实的值（很大），
  第一次
  c:SYN=1,seq = 123456, len = 100
  s:SYN=1,ack=1,seq=234567（1461）
  第二次
  c:seq = 123456+1,len=100
  s:ack = 123456+1+100
  第三次
  s:seq=234567+1,len=100
  c:ack=234567+1+100
  

  • 三次握手
    
  • 状态解读
    • CLOSED：client处于关闭状态
    • LISSTEN：server处于监听状态，等待client连接
    • SYN-RCVD：表示serrver接受到SYN报文，当收到client的ACK报文后，他会今日到ESTABLISHED状态
    • SYN-SENT：表示client已经发送SYN报文，等待server的第二次握手
    • ESTABLISHED：表示连接已经建立
  • 前2次握手特点：
    • SYN都设置为1
    • 数据部分长度都为0
    • TCP头部的长度一般是32字节（固定部分：20字节，可选部分：12字节）
    • 双方会交换确认一些信息
    • 如：MSS、是否支持SACK、窗口缩放系数等，这些数据都放在TCP头部的选项部分中（12字节）
  • 为什么要三次？两次不行？
    • 主要目的：防止server端一直等待，浪费资源
    • 如果只用2次握手，可能出现的情况：
    • 假设client发出的第一个连接请求报文段，因为网络延迟（如果客户端迟迟收不到服务器的返回就会重新发送一个请求），在连接释放以后的某个时间才到达server
    • 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出一个新的连接请求
    • 于是server就向client发出确认报文段，同意建立连接
    • 如果不采用三次握手，那么只要server发出确认，新的连接就建立了
    • 但是由于现在的client并没有真正想连接服务器的意愿，因此不理睬serverr的确认，也不会向serverrr发送数据
    • 采用三次握手的办法开源防止上述现象发送
    • 如上述情况，client没有向server的确认发出确认，serrver由于收不到确认，就知道client并没有要求建立连接
    • 第三次握手失败了，会怎么处理？
    • 此时server的状态为SYN-RECV，若等不到client的ACK，server会重新发送SYN+ACK包
    • 如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接
      

• 释放连接

  • 四次挥手
    

  上图，就是四次挥手的大致过程
  客户端先发出释放连接请求到服务器
  服务器回复确认收到释放连接请求到客户端
  
  （一般来说当服务器没有数据需要发送时）
  服务器发送释放连接请求给客户端
  客户端回复确认收到释放连接请求给服务器
  

  • 为什么要四次挥手？
    1. TCP是全双工通信模式
    2. 第一次挥手：当主机1发出FIN报文段时
    3. 表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
    4. 第二次挥手：当主机2返回ACK报文段时
    5. 表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的
    6. 第三次挥手：当主机2也发送了FIN报文段时
    7. 表示主机2告诉主机1，主机2已经没有数据要发送了
    8. 第四次挥手：当主机1返回ACK报文段时
    9. 表示主机1已经知道主机2没有数据发送了，随后正式断开整个TCP连接
  • 细节：
    • TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开
    • client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
    • 一般是等待2倍的MSL (Maximum Segment Lifetime，最大分段生存期)
    • MSL是TCP报文在Internet上的最长生存时间
    • 每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟
    • 如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN
    • 这时可能出现的情况是：
    • 1.client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
    • 2.client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的
  • 状态解读
    • FIN-WAIT-1∶表示想主动关闭连接
    • 向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
    • CLOSE-WAIT : 表示在等待关闭
    • 当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
    • 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
    • FIN-WAIT-2:只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
    • CLOSING:一种比较罕见的例外状态
    • 表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
    • 如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
    • 表示双方都正在关闭SOCKET连接
      
    • LAST-ACK:被动关闭一方在发送FIN报文后，最后等待对方的ACK报文
    • 当收到ACK报文后，即可进入CLOSED状态了
    • TIME-WAIT:表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可进入CLOSED状态了
    • 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时
    • 可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态
    • CLOSED:关闭状态
    • 由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD、FIN-WAIT-1等
  • 代码+抓包演示:

    • 抓包，从开始到关闭
      
      

    • 说明：

RST的意思是表示强制关闭，不是正常的关闭
ps：
建立连接后，服务器一般是不会主动关闭连接，会一直在等客户端发送数据
在实际开发中，一般会在客户端进行保活（发送心跳包），服务器会监听连接，当一定时间内
没有心跳时，就关闭连接，减少资源浪费

TCP也有这个机制：
keep-alive,设置时长完成心跳包的发送，但开发中一般是由自己实现

ps:
有时候在使用抓包工具的时候，有可能只会看到“3次“挥手
这其实是将第2、3次挥手合并了
当server接收到client的FIN时，如果server后面也没有数据要发送给client了I这时，server就可以将第2、3次挥手合并，同时告诉client两件事
已经知道client没有数据要发
server已经没有数据要发了

• 代码

import java.io.*;
import java.net.Socket;
import java.util.Scanner;


public class Client {

    // 1. 启动客户端(一定不要绑定端口号) 和服务器建立连接
    // 2. 进入主循环
    //  a) 读取用户输入内容
    //  b) 构造一个请求发送给服务器
    //  c) 读取服务器的响应数据
    //  d) 把响应数据显示到界面上.
    private Socket socket=null;

    public Client(String socketIP,int socketPort) throws IOException {
        socket=new Socket(socketIP,socketPort);
    }

    public void start() throws IOException {
        System.out.println("启动客户端");
        Scanner scanner=new Scanner(System.in);
        try(BufferedReader bufferedReader=new BufferedReader(new InputStreamReader(socket.getInputStream()));
            BufferedWriter bufferedWriter=new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()))) {
            while(true){
                System.out.print("-> ");
                String request=scanner.nextLine();
                if("exit".equals(request)){
                    break;
                }
                //发送给服务器
                bufferedWriter.write(request+"\n");
                //刷新 因为写入到缓冲区中并没有写入到内核中
                bufferedWriter.flush();
                //读取服务器中的内容
//                String response=bufferedReader.readLine();
//                System.out.println(response);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }finally {
            socket.close();
        }
    }

    public static void main(String[] args) throws IOException {
        Client client=new Client("127.0.0.1",8888);
        client.start();

    }


}

import java.io.*;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Scanner;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;


public class Server {
    private ServerSocket serverSocket=null;

    public Server(int port) throws IOException {
        //绑定端口号
        serverSocket=new ServerSocket(port);
    }

    public void start() throws IOException {
        System.out.println("服务器启动");
        //创建一个线程池
        ExecutorService executorService= Executors.newCachedThreadPool();
        while(true){
            //先从内核中获取到TCP连接
            Socket clientSocket=serverSocket.accept();
            //处理这个连接
            //我们可以在这个地方加上一个线程池
            executorService.execute(new Runnable() {
                @Override
                public void run() {
                    try {
                        processConnection(clientSocket);
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                }
            });
        }
    }

    private void processConnection(Socket clientSocket) throws IOException {
        //获取地址和端口
        System.out.printf("[%s:%d] 客户端上线 \n",clientSocket.getInetAddress().toString(),clientSocket.getPort());
        try(BufferedReader bufferedReader=new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
            BufferedWriter bufferedWriter=new BufferedWriter(new OutputStreamWriter(clientSocket.getOutputStream()))){
            //长连接版本服务器
            while(true){
                //读取
                String request=bufferedReader.readLine();
                //处理数据
                String response=process(request);
                //将这个返回给客户端
//                bufferedWriter.write(response+"\n");
//                bufferedWriter.flush();

                //写一个日志
//                System.out.printf("[%s:%d] req:%s,resq:%s\n",clientSocket.getInetAddress().toString()
//                        ,clientSocket.getPort(),request,response);
                System.out.printf("[%s:%d] req:%s\n",clientSocket.getInetAddress().toString()
                        ,clientSocket.getPort(),request);
            }
        } catch (IOException e) {
            //e.printStackTrace();
            System.out.printf("[%s:%d] 客户端下线\n",clientSocket.getInetAddress().toString(),clientSocket.getPort());
            serverSocket.close();
            clientSocket.close();

        }
    }

    private String process(String request) {
        return request;
    }

    public static void main(String[] args) throws IOException {
        Server server=new Server(8888);
        server.start();
    }
}

• 长连接和短连接：
  • 短连接：拿完数据就关闭
  • 长连接：拿完数据不会马上关闭

应用层

主要使用协议：

• 超文本传输:HTTP、HTTPS
• 文件传输:FTP
• 电子邮件:SMTP、POP3、IMAP
• 动态主机配置:DHCP
• 域名系统:DNS

域名

• 由于IP地址不方便记忆，并且不能表达组织的名称和性质，人们设计出了域名（比如baidu.com)
  • 但实际上，为了能够访问到具体的主机，最终还是得知道目标主机的IP地址
  • 域名申请注册: https://wanwang.aliyun.com/
• 那干脆全程直接用域名，不用IP地址?
  • IP地址固定4个字节，域名随随便便都至少10几个字节，这无疑会增加路由器的负担，浪费流量
• 根据级别不同，域名可以分为
  • 顶级域名(Top-level Domain，简称TLD)
    • 通用顶级域名（General Top-level Domain，简称gTLD)
    • .com（公司)，.net（网络机构)，.org(组织机构)，.edu(教育).gov(政府部门)，.int（国际组织）等
    • 国家及地区顶级域名(Country Code Top-level Domain，简称ccTLD)
    • .cn(中国)、jp(日本)、.uk(英国)
    • 新通用顶级域名(New Generic Top-level Domain，简称:New gTLD)
    • .vip、.xyz、.top、.club、.shop等
  • 二级域名
    • 二级域名是指顶级域名之下的域名
    • 在通用顶级域名下，它一般指域名注册人的名称，例如google、baidu、microsoft等
    • 在国家及地区顶级域名下，它一般指注册类别的，例如com、edu、gov、net等
      
      • 如 xxx.com.cn、xxx.edu.cn
  • 三级域名
  • …

DNS

DNS介绍

• DNS的全称是:Domain Name System，译为:域名系统
• 利用DNS协议，可以将域名（比如baidu.com）解析成对应的IP地址（比如220.181.38.148)
• DNS可以基于UDP协议，也可以基于TCP协议，服务器占用53端口

DNS常用命令

• ipconfig /displaydns:查看DNS缓存记录
• ipconfig /displaydns:查看DNS缓存记录
• ping 域名
• nslookup域名

DNS服务器

• 客户端首先会访问最近的一台DNS服务器（也就是客户端自己配置的DNS服务器)
• 所有的DNS服务器都记录了DNS根域名服务器的IP地址
• 上级DNS服务器记录了下一级DNS服务器的IP地址
• 全球—共13台IPv4的DNS根域名服务器、25台IPv6的DNS根域名服务器

DHCP

IP地址分配

• IP地址按照分配方式，可以分为:静态IP地址、动态IP地址
  • 静态lP地址
    • 手动设置
    • 适用场景:不怎么挪动的台式机(比如学校机房中的台式机)、服务器等
  • 动态IP地址
    • 从DHCP服务器自动获取IP地址适用场景:移动设备、无线设备等

介绍

• DHCP (Dynamic Host Configuration Protocol)，译为:动态主机配置协议
  • DHCP协议基于UDP协议，客户端是68端口，服务器是67端口
• DHCP服务器会从IP地址池中，挑选一个IP地址“出租“给客户端一段时间，时间到期就回收它们
  • 平时家里上网的路由器就可以充当DHCP服务器

DHCP分配IP地址的4个阶段

• DISCOVER:发现服务器
  • 发广播包（源IP是0.0.0.0，目标IP是255.255.255.255，目标MAC是FF:FF:FF:FF:FF:FF)
• OFFER:提供租约
  • 服务器返回可以租用的IP地址，以及租用期限、子网掩码、网关、DNS等信息注意:这里可能会有多个服务器提供租约
• REQUEST:选择lP地址
  • 客户端选择一个OFFER，发送广播包进行回应
• ACKNOWLEDGE:确认
  • 被选中的服务器发送ACK数据包给客户端
  • 至此，IP地址分配完毕
    

DHCP细节

• DHCP服务器可以跨网段分配IP地址么?(DHCP服务器、客户端不在同一个网段)
  • 可以借助DHCP中继代理(DHCP Relay Agent)实现跨网段分配IP地址
• 自动续约
  • 客户端会在租期不足的时候，自动向DHCP服务器发送REQUEST信息申请续约
• 常用命令
  • ipconfig /all:可以看到DHCP相关的详细信息，比如租约过期时间、DHCP服务器地址等
  • ipconfig /release:释放租约
  • lipconfig /renew:重新申请lP地址、申请续约(延长租期)

HTTP

介绍

• HTTP (Hyper Text Transfer Protocol)，译为超文本传输协议
  • 是互联网中应用最广泛的应用层协议之一
  • 设计HTTP最初的目的是:提供一种发布和接收HTML页面的方法，由URI来标识具体的资源
  • URL是URI的一部分,相当于URI>URL
  • 后面用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛
• HTML ( Hyper Text Markup Language):超文本标记语言
  • 用以编写网页

版本

• 1991年，HTTP/0.9
  • 只支持GET请求方法获取文本数据〈比如HTML文档)，且不支持请求头、响应头等，无法向服务器传递太多信息
• 1996年，HTTP/1.0
  • 支持POST、HEAD等请求方法，支持请求头、响应头等，支持更多种数据类型（不再局限于文本数据)浏览器的每次请求都需要与服务器建立一个TCP连接，请求处理完成后立即断开TCP连接
• 1997年，HTTP/1.1(最经典、使用最广泛的版本)
  • 支持PUT、DELETE等请求方法
  • 采用持久连接(Connection: keep-alive)，多个请求可以共用同一个TCP连接
• 2015年，HTTP/2.0
• 2018年，HTTP/3.0

标准

• HTTP的标准
  • 由万维网协会(W3C)、互联网工程任务组（IETF）协调制定，最终发布了一系列的RFC
• RFC (Request For Comments，可以译为:请求意见稿)
  • HTTP/1.1最早是在1997年的RFC2068中记录的
  • 该规范在1999年的RFC 2616中已作废
  • 2014年又由RFC 7230系列的RFC取代
  • lHTTP/2标准于2015年5月以RFC 7540正式发表，取代HTTP/1.1成为HTTP的实现标准
• 中国的RFC
  • 1996年3月，清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC1922成为中国大陆第一个被认可为RFC文件的提交协议

报文格式

request

response

• 请求报文
  

• 响应报文
  

• 实体主体（一般是post的请求体）
  

ABNF

• ABNF (Augmented BNF)
• 是BNF (Backus-Naur Form，译为:巴科斯-瑙尔范式)的修改、增强版在RFC 5234中表明:ABNF用作internet中通信协议的定义语言
• ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是片面、不严谨的
• 关于HTTP报文格式的定义关于HTTP报文格式的定义
• RFC 2616 4.HTTP Message (l日)
• RFC 7230 3.Message Format(新)

整体

• 总体

HTTP-message = start-line
				*( header-field CRLF)
				CRLF
				[ message-body ]
start-line = request-line /  status-line

	说明
/	任选一个
*	0个或多个。2表示至少2个，36表示3到6个
()	组成一个整体
[]	可选(可有可无)

• 开始行

request-line = method SP request-target SP HTTP-version CRLF
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ;HTTP

GET / hello/ HTTP/1.1

ps:
sp=space
%x48.54.54.50 = %x48 . %x54 . %x54 . %x50 = HTTP

• 开始行说明

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase = *( HTAB / SP / VCHAR / obs-text )

HTTP/1.1 200
HTTP/1.1 200 oK
reason-phrase(描述)

• 头文件(请求头)和请求体说明

header-fie1d = field-name " :" OWS fie1d-value OWS 
field-name = token
field-value = *( field-content / obs-fold )

OWS = *( SP / HTAB ) = 0个或多个，空格或TAB

message-body = *OCTET
OCTET = 8位 = 1字节
ps:
1字符 = 2字节 = 16（位）也就是16（bit），16位二进制

URL编码

请不用对别人的服务器做出奇怪的事情

• URL中一旦出现了一些特殊字符（比如中文、空格)，需要进行编码
• 在浏览器地址栏输入URL时，是采用UTF-8进行编码
• 比如
• 编码前:https://www.baidu.com/s?wd=百度
• 编码后: https://www.baidu.com/s?wd=%E5%8D%8E%E4%B8%BA

xshell+telnet

• 安装一个Xshell(安全终端模拟软件)，在Xshell中使用telnet
• 可以直接面向HTTP报文与服务器交互
• 可以更清晰、直观地看到请求报文、响应报文的内容
• 可以检验请求报文格式的正确与否
• 启动服务器

telnet localhost 8080

Host 'localhost' resolved to ::1.
Connecting to ::1:8080...
Connection established.
To escape to local shell, press 'Ctrl+Alt+]'.

GET /hello/ HTTP/1.1

GET / HTTP/1.1
Host: localhost:8080 //其实还是要加上

请求方法

• RFC 7231, section 4: Request methods:描述了8种请求方法
  • GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE
• RFC 5789,section 2: Patch method:描述了PATCH方法
• GET:常用于读取的操作，请求参数直接拼接在URL的后面(浏览器对URL是有长度限制的)
• POST:常用于添加、修改、删除的操作，请求参数可以放到请求体中（没有大小限制)
• HEAD:请求得到与GET请求相同的响应，但没有响应体
  • 使用场景举例:在下载一个大文件前，先获取其大小，再决定是否要下载。以此可以节约带宽资源
• OPTIONS:用于获取目的资源所支持的通信选项，比如服务器支持的请求方法
  • OPTIONS * HTTP/1.1
• PUT:用于对已存在的资源进行整体覆盖
• PATCH:用于对资源进行部分修改（资源不存在，会创建新的资源)
• DELETE:用于删除指定的资源
• TRACE:请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断
• CONNECT:可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道(tunnel)
  • 可以用来访问采用了SSL (HTTPS)协议的站点

头字段

• 头部字段可以分为4种类型
  • 请求头字段(Request Header Fields)
    • 有关要获取的资源或客户端本身信息的消息头
  • 响应头字段(Response Header Fields)
    • 有关响应的补充信息，比如服务器本身（名称和版本等)的消息头
  • 实体头字段(Entity Header Fields)
    • 有关实体主体的更多信息，比如主体长度(Content-Length)或其MIME类型
  • 通用头字段(General Header Fields)
    • 同时适用于请求和响应消息，但与消息主体无关的消息头

请求头说明

头字段名	说明	示例
User-Agent	浏览器的身份标识字符串	user-Agent: Mozilla/5.0 (×11;Linux x86_64; rv :12.0)Gecko/ 20108101 Firefox/21.0
Host	服务器的域名、端口号	Host: localhost :88
Date	发送该消息的日期和时间	Date: Tue,15 Nov 199408:12:31 GMT
Referer	表示浏览器所访问的前一个页面，正是那个页面上的某个链接将浏览器带到了当前所请求的这个页面	Referer: https : / / www . baidu.com
content-Type	请求体的类型	content-Type: multipart/form-data
Content-Length	请求体的长度（字节为单位)	content-Length: 348
Accept	能够接受的响应内容类型(Content-Types)	Accept : text/plain
Accept-Charset	能够接受的字符集	Accept-Charset: utf-8
Accept-Encoding	能够接受的编码方式列表	Accept-Eneoding: gzip, deflate
Accept-Language	能够接受的响应内容的自然语言列表	Accept-Language: en-us
Range	仅请求某个实体的一部分。字节偏移以0开始	Range: bytes=500-999
origin	发起一个针对跨域资源共享的请求	origin: https : / / www.baidu.comorigin: https : / / www.baidu.com
cookie	之前由服务器通过Set-Cookie发送的Cookie	Cookie: sversion=1; Skin=new;
connection	该浏览器想要优先使用的连接类型	connection: keep-alive
Cache-Control	用来指定在这次的请求/响应链中的所有缓存机制都必须遵守的指令	Cache-Control: no-cache

响应头说明

头字段名	说明	示例
Date	发送该消息的日期和时间	Date: Tue,15 Nov 1994 08:12:31 GMT
Last-Modified	所请求的对象的最后修改日期	Last-Modified: Tue,15 Nov 1994 12:45:26GMT
Server	服务器的名字	Server: Apache/2.4.1 (Unix)
Expires	指定一个时间，超过该时间则认为此响应已经过期	Expires: Thu, 01 Dec 1994 16:08:0e GMT
Content-Type	响应体的类型	Content-Type: text/html; charset=utf-8
content-Encoding	内容所使用的编码类型	content-Encoding: gzip
content-Length	响应体的长度（字节为单位)	content-Length: 348
content-Disposition	一个可以让客户端下载文件并建议文件名的头部	Content-Disposition: attachment;Content-Disposition: attachment;filename=“fname.ext”
Accept-Ranges	服务器支持哪些种类的部分内容范围	Accept-Ranges: bytes
content-Range	这条部分消息是属于完整消息的哪部分	Content-Range: bytes 21810-47021/47822
Access-control-Allow-origin	指定哪些网站可参与到跨来源资源共享过程中	Access-Control-Allow-origin:*
Location	用来进行重定向，或者在创建了某个新资源时使用	Location: http: / / www.w3.org
Set-Cookie	返回一个Cookie让客户端去保存	set-Cookie: UserID=JohnDoe; Max一Age=3680; version=1
Connection	针对该连接所预期的选项	Connection: close
cache-Control	向从服务器直到客户端在内的所有缓存机制告知。它们是否可以缓存这个对象。单位为秒	Cache-Control: max-age=3600

状态码

• 在RFC261610.Status Code Definitions规范中定义
  • 状态码指示HTTP请求是否已成功完成
• 状态码可以分为5类
  • 信息响应:100~199
  • 成功响应:200~299
  • 重定向:300~399
  • 客户端错误:400~499
  • 服务器错误:500~599

常见的状态码

• 100 Continue
  • 请求的初始部分已经被服务器收到，并且没有被服务器拒绝。客户端应该继续发送剩余的请求，如果请求已经完成，就忽略这个响应
  • 允许客户端发送带请求体的请求前，判断服务器是否愿意接收请求（服务器通过请求头判断)
  • 在某些情况下，如果服务器在不看请求体就拒绝请求时，客户端就发送请求体是不恰当的或低效的
• 200 OK:请求成功
• 302 Found:请求的资源被暂时的移动到了由Location头部指定的URL上
• 304 Not Modified:说明无需再次传输请求的内容，也就是说可以使用缓存的内容
• 400 Bad Request:由于语法无效，服务器无法理解该请求
• 401 Unauthorized:由于缺乏目标资源要求的身份验证凭证
• 403 Forbidden:服务器端有能力处理该请求，但是拒绝授权访问
• 404 Not Found:服务器端无法找到所请求的资源
• 405 Method Not Allowed:服务器禁止了使用当前HTTP方法的请求
• 406 Not Acceptable:服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应
• 408 Request Timeout:服务器想要将没有在使用的连接关闭
  - 一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下
• 500 lnternal Server Error:所请求的服务器遇到意外的情况并阻止其执行请求
• 501 Not lmplemented:请求的方法不被服务器支持，因此无法被处理
  • 服务器必须支持的方法（即不会返回这个状态码的方法)只有GET和HEAD
• 502 Bad Gateway:作为网关或代理角色的服务器，从上游服务器(如tomcat)中接收到的响应是无效的
• 503 Service Unavailable:服务器尚未处于可以接受请求的状态
  - 通常造成这种情况的原因是由于服务器停机维护或者已超载

form提交

常用属性

• action:请求的URI
• method:请求方法（GET、POST)
• enctype: POST请求时，请求体的编码方式
  • application/x-www-form-urlencoded(默认值)
  • 用&分隔参数，用=分隔键和值，字符用URL编码方式进行编码
• multipart/form-data
  • 文件上传时必须使用这种编码方式

multipart/form-data

• 参考RFC 1521
• 请求头
• Content-Type: multipart/form-data; boundary=xxX

multipart-body := preamble 1*encapsulation close-delimiter epilogue
encapsulation := delimiter body-part CRLF
delimiter := "--" boundary CRLF ; taken from Content-Type field.; There must be no space between "--" and boundary.
close-delimiter := “--" boundary "--”CRLF ; Again, no space by "--"
preamble := discard-text; to be ignored upon receipt.
epilogue := discard-text; to be ignored upon receipt.

跨域

同源策略

• 浏览器有个同源策略(Same-origin Policy)
• 它规定了:默认情况下，AJAX请求只能发送给同源的URL
• 同源是指3个相同:协议、域名( IP)、端口
• img.script、link、iframe、video、audio等标签不受同源策略的约束
  

跨域资源共享

• 解决AJAX跨域请求的常用方法
  • CORS (cross-origin Resource Sharing) ，跨域资源共享
• CORS的实现需要客户端和服务器同时支持
  • 客户端
    • 所有的浏览器都支持(IE至少是IE10版本)
  • 服务器
    • 需要返回相应的响应头（比如Access-Contro1-Allow-origin)
    • 告知浏览器这是一个允许跨域访问的请求

Cookie

Cookie作用域

• domain和path标识定义了Cookie的作用域，即Cookie应该发送给哪些URL
  • domain
    • 标识指定了哪些主机可以接受Cookie
    • 如果不指定，默认为当前文档的主机(不包含子域名)﹔如果指定了domain，则一般包含子域名
    • 例如:如果设置domain=520it.com，则Cookie也包含在子域名中(如bbs.520it.com）
  • path
    • 标识指定了主机下的哪些路径可以接受Cookie，子路径也会被匹配1例如:设置path=/docs，则以下地址都会匹配
    • /docs
    • /docs/one/
    • /docs/one/img

会话跟踪

• HTTP是一种“无状态”(stateless)的协议
• 每次客户端访问网页时，客户端都会打开与web服务器的单独连接
• 并且服务器不会自动保留之前客户端请求的任何记录
• 所以服务器无法识别多个请求是否来自同一个客户端（比如浏览器)
• 在很多应用场景中，都有以下需求
  • 服务器能够识别出多个请求是否来自同一个客户端I在来自同一个客户端的多个请求之间共享数据
  • 以上需求可以使用会话跟踪技术来完成。在Java中，实现会话跟踪的常用方案是
    • Cookie
    • session

Cookie

• Cookie是直接存储在浏览器本地的一小串数据
  • 使用document.cookie访问Cookie
  • 修改Cookie时，只会修改其中提到的Cookie
    • name=value必须被编码(encodeURIComponent)
• 一个Cookie最大为4kb，每个网站最多有20+个左右的Cookie(具体取决于浏览器)
• windows中Chrome浏览器的Cookie存放位置
  • C: \Users\用户名\AppData\Local\Google\Chrome\User Data\Default\Cookies
  • 使用SQLite数据库进行存储

有效期

• 如果没有设置Cookie的过期时间，则当浏览器关闭时，Cookie就失效了
• expires
  • 必须完全采用GMT时区的格式，可以使用date.toUTCString来获取
  • 例如: expires=Tue,19 Jan 2038 03:14∶07 GMT
• max-age
  • 过期时间距离当前时间的秒数
  • 例如: max-age=60

服务器设置

• Cookie通常是由web服务器使用响应头Set-Cookie设置的
• 关于max-age
  • 在JavaScript中:如果设置为0或者负数，会立即删除Cookie
  • 在Java中:如果设置为0，是立即删除Cookie;如果设置为负数，按默认情况处理

Java中getSession()原理

• 检查客户端是否有发送一个叫做JSESSIONID的Cookie
  • 如果没有
    • 创建一个新的Session对象，并且这个Session对象会有一个id这个Session对象会保留在服务器的内存中
    • 在响应的时候，会添加一个Cookie (JSESSIONID=Session对象的id)给客户端
  • 如果有
    • 返回id为JSESSIONID的Session对象

JSESSIONID

• 默认情况下，当用户关闭浏览器时，Cookie中存储的JSESSIONID就会被销毁
• 可以通过代码延长JSESSIONID在客户端的寿命

Session

Session有效期

• session的有效期默认是30分钟
• 可以通过服务器设置

Session和Cookie总结

• Cookie
  • 数据存储在浏览器客户端
  • 数据有大小和数量的限制
  • 适合存储一些小型、不敏感的数据
  • 默认情况下，关闭浏览器后就会销毁
• Session
  • 数据存储在服务器端
  • 数据没有大小和数量的限制
  • 可以存储大型、敏感的数据（比如用户信息)
  • 默认情况下，未使用30分钟后就会销毁

代理服务器(Proxy Server)

特点

• 本身不生产内容
• 处于中间位置转发上下游的请求和响应
• 面向下游的客户端:它是服务器
• 面向上游的服务器:它是客户端
  

正向代理、反向代理

• 正向代理:代理的对象是客户端
• 反向代理:代理的对象是服务器
  
  
• 正向代理
  • 隐藏客户端身份
  • 绕过防火墙（突破访问限制)
  • lnternet访问控制
  • 数据过滤
    
• 反向代理
  • 隐藏服务器身份
  • 安全防护
  • 负载均衡
    

抓包工具的原理

• Fiddler、Charles等抓包工具的原理:在客户端启动了正向代理服务
  
• Wireshark的原理是:通过底层驱动，拦截网卡上流过的数据

相关头部字段

• Via:追加经过的每一台代理服务器的主机名(或域名)
• X-Forwarded-For:追加请求方的IP地址
• X-Real-IP:客户端的真实IP地址

CDN

• CDN (Content Delivery Network或Content Distribution Network)，译为:内容分发网络
• 利用最靠近每位用户的服务器
• 更快更可靠地将音乐、图片、视频等资源文件（一般是静态资源）传递给用户
• 使用前后
  
• CDN运营商在全国、乃至全球的各个大枢纽城市都建立了机房
  • 部署了大量拥有高存储高带宽的节点，构建了一个跨运营商、跨地域的专用网络

网络通信安全

• 截获:窃听通信内容
• 中断:中断网络通信
• 篡改:篡改通信内容
• 伪造:伪造通信内容

网络层-ARP欺骗

• ARP欺骗(ARP spoofing)，又称ARP毒化(ARP poisoning)、 ARP病毒、ARP攻击

• ARP欺骗可以造成的效果

  • 可让攻击者获取局域网上的数据包甚至可篡改数据包
  • 可让网络上特定电脑之间无法正常通信（例如网络执法官这样的软件)
  • 让送至特定IP地址的流量被错误送到攻击者所取代的地方

• ARP欺骗-核心步骤

  • 假设主机C是攻击者，主机A、B是被攻击者
    • C只要收到过A、B发送的ARP请求，就会拥有A、B的IP、MAC地址，就可以进行欺骗活动
    • C发送一个ARP响应给B，把响应包里的源IP设为A的IP地址，源MAC设为C的MAC地址
    • B收到ARP响应后，更新它的ARP表，把A的MAC地址(IP_A, MAC_A)改为(IP_A, MAC_C)
    • 当B要发送数据包给A时，它根据ARP表来封装数据包的头部，把目标MAC地址设为MAC_C，而非MAC_A
    • 当交换机收到B发送给A的数据包时，根据此包的目标MAC地址(MAC_C)而把数据包转发给C
    • C收到数据包后，可以把它存起来后再发送给A，达到窃听效果。C也可以篡改数据后才发送数据包给A

• ARP 防护

  • 静态ARP
  • DHCP Snooping
    • 网络设备可借由DHCP保留网络上各电脑的MAC地址，在伪造的ARP数据包发出时即可侦测到
  • 利用一些软件监听ARP的不正常变动（360啊，腾讯电脑管家这些）

DOS、DDOS

• DoS攻击(拒绝服务攻击，Denial-of-Service attack)
  • 使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问
• DDoS攻击(分布式拒绝服务攻击，Distributed Denial-of-Service attack)
  • 黑客使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动DoS攻击
  • 2018年3月，GitHub遭到迄今为止规模最大的DDoS攻击
• DoS攻击可以分为2大类
  • 带宽消耗型:UDP洪水攻击、ICMP洪水攻击
  • 资源消耗型:SYN洪水攻击、LAND攻击
• SYN洪水攻击(SYN flooding attack)
  • 攻击者发送一系列的SYN请求到目标，然后让目标因收不到ACK(第3次握手）而进行等待、消耗资源
  • 攻击方法
    • 跳过发送最后的ACK信息
    • 修改源IP地址，让目标送SYN-ACK到伪造的IP地址，因此目标永不可能收到ACK(第3次握手)
  • 防护
    • 参考:RFC 4987参考:RFC 4987
• LAND攻击（局域网拒绝服务攻击，Local Area Network Denial attack)
  • 通过持续发送相同源地址和目标地址的欺骗数据包，使目标试图与自己建立连接，消耗系统资源直至崩溃
  • 有些系统存在设计上的缺陷，允许设备接受并响应来自网络、却宣称来自于设备自身的数据包，导致循环应答
  • 防护
    • 大多数防火墙都能兰截类似的攻击包，以保护系统
    • 部分操作系统通过发布安全补丁修复了这一漏洞
    • 路由器应同时配置上行与下行筛选器，屏蔽所有源地址与目标地址相同的数据包
• DOS、DDOS防御方式
  • 防御方式通常为:入侵检测、流量过滤、和多重验证
  • 堵塞网络带宽的流量将被过滤，而正常的流量可正常通过
  • 防火墙
    • 防火墙可以设置规则，例如允许或拒绝特定通讯协议，端口或lP地址
    • 当攻击从少数不正常的IP地址发出时，可以简单的使用拒绝规则阻止一切从攻击源IP发出的通信
    • 复杂攻击难以用简单规则来阻止，例如80端口遭受攻击时不可能拒绝端口所有的通信，因为同时会阻止合法流量
    • 防火墙可能处于网络架构中过后的位置，路由器可能在恶意流量达到防火墙前即被攻击影响
  • 交换机:大多数交换机有一定的速度限制和访问控制能力
  • 路由器:和交换机类似。路由器也有一定的速度限制和访问控制能力
  • 黑洞引导
    • 将所有受攻击计算机的通信全部发送至一个“黑洞”(空接口或不存在的计算机地址)或者有足够能力处理洪流的网络设备商，以避免网络受到较大影响
  • 流量清洗
    • 当流量被送到DDoS防护清洗中心时，通过采用抗DDoS软件处理，将正常流量和恶意流量区分开正常的流量则回注回客户网站

应用层-DNS劫持

• DNS劫持，又称为域名劫持
  • 攻击者篡改了某个域名的解析结果，使得指向该域名的IP变成了另一个IP
  • 导致对相应网址的访问被劫持到另一个不可达的或者假冒的网址
  • 从而实现非法窃取用户信息或者破坏正常网络服务的目的
• 为防止DNS劫持，可以考虑使用更靠谱的DNS服务器
  • 比如:114.114.114.114
  • 谷歌:8.8.8.8、8.8.4.4
  • 微软:4.2.2.1、4.2.2.2
  • 百度:180.76.76.76
  • 阿里:223.5.5.5、223.6.6.6
• HTTP劫持:对HTTP数据包进行拦截处理，比如插入JS代码
  • 比如你访问某些网站时，在右下角多了个莫名其妙的弹窗广告

HTTP 安全协议问题

• HTTP协议默认是采取明文传输的，因此会有很大的安全隐患
• 常见的提高安全性的方法是:对通信内容进行加密后，再进行传输
• 常见的加密方式有
  • 不可逆
    • 单向散列函数:MD5、SHA等
  • 可逆
    • 对称加密:DES、3DES、AES等
    • 非对称加密:RSA等
  • 其它
    • 混合密码系统
    • 数字签名
    • 证书
• 常见单词
  • encrypt:加密
  • decrypt:解密
  • plaintext:明文
  • ciphertext:密文

模拟

• Alice、Bob:互相通信
• Eve:窃听者
• Mallory :主动攻击者
  
  
• 防止窃听（比较简单的）
  

单向散列函数

• 单向散列函数，可以根据根据消息内容计算出散列值
• 散列值的长度和消息的长度无关，无论消息是1bit、10M、100G，单向散列函数都会计算出固定长度的散列值
  
• 特点
  - 根据任意长度的消息，计算出固定长度的散列值
  - 计算速度快，能快速计算出散列值
  - 消息不同，散列值也不同
  - 具备单向性（不可逆）
  
  
• 称呼
  • 单向散列函数，也被称为
    • 消息摘要函数(message digest function)
    • 哈希函数(hash function)
  • 输出的散列值，也被称为
    • 消息摘要(message digest)
    • 指纹(fingerprint)
• 常见的单向散列函数
  • MD4、MD5
    • 产生128bit的散列值，MD就是Message Digest的缩写，目前已经不安全
  • SHA-1
    • 产生160bit的散列值，目前已经不安全
  • SHA-2
    • SHA-256、SHA-384、SHA-512，散列值长度分别是256bit、384bit、512bit
  • SHA-3
    • 全新标准
• 防止数据被篡改
  
  
  

对称加密

• 常见的加密算法
  • DES(Data Encryption Standard)
    
    • DES是一种将64bit明文加密成64bit密文的对称加密算法，密钥长度是56bit
    • 规格上来说，密钥长度是64bit，但每隔7bit会设置一个用于错误检查的bit，因此密钥长度实质上是56bit
    • 由于DES每次只能加密64bit的数据，遇到比较大的数据，需要对DES加密进行迭代（反复)
    • 目前已经可以在短时间内被破解，所以不建议使用
  • 3DES(Triple Data Encryption Algorithm)
    • 3DES，将DES重复3次所得到的一种密码算法，也叫做3重DES
    • 三重DES并不是进行三次DES加密（(加密→加密→加密)
    • 而是加密(Encryption)→解密(Decryption)→加密(Encryption)的过程
    • 目前还被一些银行等机构使用，但处理速度不高，安全性逐渐暴露出问题
      
      
    • 3个密钥都是不同的，也称为DES-EDE3
    • 如果所有密钥都使用同一个，则结果与普通的DES是等价的
    • 如果密钥1、密钥3相同，密钥2不同，称为DES-EDE2
  • AES(Advanced Encryption Standard)
    • 取代DES成为新标准的一种对称加密算法，又称Rijndael加密法
    • AES的密钥长度有128、192、256bit三种
    • 目前AES，已经逐步取代DES、3DES，成为首选的对称加密算法
    • 一般来说，我们也不应该去使用任何自制的密码算法，而是应该使用AES
    • 它经过了全世界密码学家所进行的高品质验证工作
• 如何解决密钥配送问题
  • 事先共享密钥（比如私下共享)
  • 密钥分配中心(Key Distribution Center，简称KDC)
  • Diffie-Hellman密钥交换
  • 非对称加密

非对称加密(Asymmetric Cryptography)又叫公钥加密

• 在非对称加密中，密钥分为加密密钥、解密密钥2种，它们并不是同一个密钥
• 加密密钥:一般是公开的，因此该密钥称为公钥(public key)
  • 因此，非对称加密也被称为公钥密码(Public-key Cryptography)
• 解密密钥:由消息接收者自己保管的，不能公开，因此也称为私钥(private key)

比如：
a、b
b要发送数据给a
那么a就把a的公钥发送给b，
b用a的公钥进行加密后发送密文给a
a再用自己的私钥进行解密

• 公钥和私钥是——对应的，不能单独生成
• 一对公钥和私钥统称为密钥对(key pair)
• 由公钥加密的密文，必须使用与该公钥对应的私钥才能解密
• 由私钥加密的密文，必须使用与该私钥对应的公钥才能解密
• 目前使用最广泛的非对称加密算法是RSA
  • RSA的名字，由它的3位开发者，即Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母组成

混合密码系统

• 对称加密的缺点
  • 不能很好地解决密钥配送问题（(密钥会被)
• 非对称加密的缺点
  • 加密解密速度比较慢
• 混合密码系统:是将对称加密和非对称加密的优势相结合的方法
  • 解决了非对称加密速度慢的问题
  • 并通过非对称加密解决了对称加密的密钥配送问题
• 网络上的密码通信所用的SSL/TLS都运用了混合密码系统
• 混合密码系统-加密
  • 会话密钥( session key)
    • 为本次通信随机生成的临时密钥
    • 作为对称加密的密钥，用于加密消息，提高速度
  • 加密步骤（发送消息)
    • 首先，消息发送者要拥有消息接收者的公钥
    • 生成会话密钥，作为对称加密的密钥，加密消息
    • 用消息接收者的公钥，加密会话密钥
    • 将前2步生成的加密结果，一并发给消息接收者
  • 发送出去的内容包括
    • 用会话密钥加密的消息（加密方法:对称加密)
    • 用公钥加密的会话密钥(加密方法:非对称加密)
  • 解密步骤(收到消息)
    • 消息接收者用自己的私钥解密出会话密钥
    • 再用解密出来的会话密钥，解密消息

数字签名

• 在数字签名技术中，有以下2种行为
  • 生成签名
    • 由消息的发送者完成，通过“签名密钥”生成
  • 验证签名
    • 由消息的接收者完成，通过“验证密钥”验证
  • 如何能保证这个签名是消息发送者自己签的
    • 用消息发送者的私钥进行签名
• 数字签名的作用
  • 确认消息的完整性
  • 识别消息是否被篡改
  • 防止消息发送人否认

对称加密-非对称加密-数字签名总结

• 在非对称加密中，任何人都可以使用公钥进行加密
  
• 在数字签名中，任何人都可以使用公钥验证签名
• 数字签名，其实就是将非对称加密反过来使用
  
• 既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密
  • 公钥负责加密，私钥负责解密
• 既然是签名，那肯定是不希望有人冒充我发消息，所以只有我才能签名
  • 私钥负责签名，公钥负责验签
• 如果遭遇了中间人攻击，那么
• 公钥将可能是伪造的
• 如何验证公钥的合法性?
• 证书

证书(Certificate)

• 说到证书

• 首先联想到的是驾驶证、毕业证、英语四六级证等等，都是由权威机构认证的

• 密码学中的证书，全称叫公钥证书(Public-key Certificate，PKC)，跟驾驶证类似里面有姓名、邮箱等个人信息，以及此人的公钥

• 并由认证机构(Certificate Authority,CA)施加数字签名
• CA就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织有国际性组织、政府设立的组织
• 有通过提供认证服务来盈利的企业
• 个人也可以成立认证机构
  
  

HTTPS

介绍

• HTTPS (HyperText Transfer Protocol Secure)，译为:超文本传输安全协议
• 常称为HTTP over TLS、HTTP over sSL、HTTP Secure
• 由网景公司于1994年首次提出
  
• HTTPS的默认端口号是443 (HTTP是80)
• 现在在浏览器上输入http://www.baidu.com会自动重定向到https://www.baidu.com

SSL/TSL

• HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供合理的防护
• SSL/TLS也可以用在其他协议上，比如
  • FTP →FTPS
  • SMTP →SMTPS

介绍

• TLS (Transport Layer Security)，译为:传输层安全性协议
• 前身是SSL (Secure Sockets Layer)，译为:安全套接层
• 历史版本信息
  • SSL 1.0:因存在严重的安全漏洞，从未公开过
  • SSL 2.0: 1995年，已于2011年弃用(RFC 6176)
  • SSL 3.0: 1996年，已于2015年弃用(RFC 7568)
  • TLS 1.0: 1999年(RFC 2246)
  • TLS 1.1: 2006年(RFC 4346)
  • TLS 1.2: 2008年(RFC 5246)
  • TLS 1.3:2018年(RFC 8446)

HTTPS成本

• 证书的费用
• 加解密计算
• 降低了访问速度
• 有些企业的做法是:包含敏感数据的请求才使用HTTPS，其他保持使用HTTP

通信过程

• 总的可以分为3大阶段
  • TCP的3次握手
  • TLS的连接
  • HTTP请求和响应
    

TLS1.2的连接过程

• 协商：TLS版本、加密套件（对称加密算法、摘要算法、非对称加密算法等等）、其他消息

• 大概有10大步骤

• 图中省略了中间的ACK确认信息
  

• 第一步（Client Hello）

  • TLS的版本号
  • 支持的加密组件（Cipher Suite）列表
    • 加密组件是指所使用的加密算法及密钥长度等
  • 一个随机数（Client Random)
  • 访问百度时使用的TLS
    
    
  • 支持16种加密套件

• 第二步（Server Hello）

  • TLS的版本号
  • 选择的加密组件
    • 是从接收到的客户端加密组件列表中挑选出来的
  • 一个随机数
    

• 第三步（Certificate）

  • 服务器的公钥证书（被CA签名过的)
    

• 第四步（Server Key Exchange）

  • 用以实现ECDHE算法的其中一个参数(Server Params)
    • ECDHE是一种密钥交换算法
    • 为了防止伪造，Server Params经过了服务器私钥签名
      

• 第五步（ Server Hello Done）

  • 告知客户端:协商部分结束
  • 目前为止，客户端和服务器之间通过明文共享了
  • 而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实有效性
  • 以共享 Client Random、Server Random、Server Params

• 第六步（Client Key Exchange）

  • 用以实现ECDHE算法的另一个参数（Client Params)
    
  • 目前为止，客户端和服务器都拥有了ECDHE算法需要的2个参数:Server Params、Client Params
  • 客户端、服务器都可以
  • 使用ECDHE算法根据Server Params、Client Params计算出一个新的随机密钥串:Pre-master secret
  • 然后结合Client Random、Server Random、Pre-master secret生成一个主密钥
  • 最后利用主密钥衍生出其他密钥:客户端发送用的会话密钥、服务器发送用的会话密钥等

• 第七步（Change Cipher Spec）

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

• 第八步（Finished）

  • 包含连接至今全部报文的整体校验值(摘要)，加密（通过第六步的会话密钥进行加密）之后发送给服务器
  • 这次握手协商是否成功，要以服务器是否能够正确解密该报文作为判定标准

• 第九步、第十步

• Change Cipher Spec

• Finished（抓包中是没有Finished只要Encrypted Handshake Message）

• 到此为止，客户端服务器都验证加密解密没问题，握手正式结束
• 后面开始传输加密的HTTP请求和响应

HTTP的不足(HTTP/1.1)

• 同一时间，一个连接只能对应一个请求
  • 针对同一个域名，大多数浏览器允许同时最多6个并发连接
• 只允许客户端主动发起请求
  • 一个请求只能对应一个响应
• 同一个会话的多次请求中，头信息会被重复传输
  • 通常会给每个传输增加500~800字节的开销
  • 如果使用Cookie，增加的开销有时会达到上千字节

SPDY

介绍

• SPDY (speedy的缩写)，是基于TCP的应用层协议，它强制要求使用SSL/TLS
  • 2009年11月，Google宣布将SPDY作为提高网络速度的内部项目
• SPDY与HTTP的关系
  • SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式
  • 只需增加一个SPDY层，现有的所有服务端应用均不用做任何修改
  • SPDY是HTTP/2的前身

HTTP2

介绍

• HTTP/2，于2015年5月以RFC 7540正式发表
• 根据W3Techs的数据，截至2019年6月，全球有36.5%的网站支持了HTTP/2
• HTTP/1.1和HTTP/2速度对比
  • 测试网址1
  • 测试网址2
• HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容
  • 比如请求方法（如GET、POST) . Status Code、各种Headers等都没有改变
  • 因此，要想升级到HTTP/2
  • 开发者不需要修改任何代码
  • 只需要升级服务器配置、升级浏览器

HTTP/2的特性 - 二进制格式

• HTTP/2采用二进制格式传输数据，而非HTTP/1.1的文本格式
• 二进制格式在协议的解析和优化扩展上带来更多的优势和可能

HTTP2的基本概念

• 数据流:已建立的连接内的双向字节流，可以承载一条或多条消息
  • 所有通信都在一个TCP连接上完成，此连接可以承载任意数量的双向数据流
• 消息:与逻辑HTTP请求或响应消息对应，由一系列帧组成
• 帧: HTTP/2通信的最小单位，每个帧都包含帧头（(会标识出当前帧所属的数据流)
  • 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装

HTTP/2的特性 - 多路复用(Multiplexing)

• 客户端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来
• 并行交错地发送多个请求，请求之间互不影响
• 并行交错地发送多个响应，响应之间互不干扰
• 使用一个连接并行发送多个请求和响应
• 不必再为绕过HTTP/1.1限制而做很多工作
  • 比如image sprites、合并CSSUS、内嵌CSSUS\Base64图片、域名分片等
    
    

HTTP/2的特性 - 优先级

• HTTP/2标准允许每个数据流都有一个关联的权重和依赖关系
  • 可以向每个数据流分配一个介于1至256之间的整数
  • 每个数据流与其他数据流之间可以存在显式依赖关系
• 客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应
• 服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级
  • 在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端

• 应尽可能先给父数据流分配资源
• 同级数据流(共享相同父项)应按其权重比例分配资源
• 对应上图的1、2、3、4步
  1. A、B依赖于隐式“根数据流”，A获得的资源比例是12/16，B获得的资源比例是4/16
  2. D依赖于根数据流，C依赖于D，D应先于C获得完整资源分配
  3. D应先于C获得完整资源分配，C应先于A和B获得完整资源分配，B获得的资源是A所获资源的1/3
  4. D应先于E和C获得完整资源分配，E和C应先于A和B获得相同的资源分配，B获得的资源是A所获资源的1/3

HTTP/2的特性 - 头部压缩

• HTTP/2使用HPACK压缩请求头和响应头
• 可以极大减少头部开销，进而提高性能
• 早期版本的HTTP/2和SPDY使用zlib压缩
• 可以将所传输头数据的大小减小85%~88%
• 但在2012年夏天，被攻击导致会话劫持
• 后被更安全的HPACK取代
  

HTTP/2的特性 - 服务器推送（Server Push）

• 服务器可以对一个客户端请求发送多个响应(还是要客户端先发送请求)
• 除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求
  
  

HTTP/2的问题 - 队头阻塞(head of line blocking)

• 底层还是用的是TCP，TCP中数据是要保证顺序的，如果取出数据时，某一部分数据丢失了，那么就只能重新发送
  
• QUIC协议底层是使用了UDP，所以就算是数据丢失，也可以不用重新发送
  
  

HTTP/2的问题 - 握手延迟

• RTT (Round Trip Time) :往返时延，可以简单理解为通信一来一回的时间

HTTP3

介绍

• Google觉得HTTP/2仍然不够快，于是就有了HTTP/3
• HTTP/3由Google开发，弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
• QuIC(Quick UDP Internet Connections)，译为:快速UDP网络连接，由Google开发，在2013年实现
• 于2018年从HTTP-over-QUIC改为HTTP/3
  

保证可靠传输

• 由QUIC来保证
• Google这么牛逼，为何不开发一个新的不同于TCP、UDP的传输层协议?
  • 目前世界上的网络设备基本只认TCP、UDP
  • 如果要修改传输层，意味着操作系统的内核也要修改
  • 另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用
  • 因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情

HTTP/3的特性 - 连接迁移

• TCP基于4要素（源IP、源端口、目标P、目标端口)
  • 切换网络时至少会有一个要素发生变化，导致连接发生变化
  • 当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
  • 所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
  • 如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒的时间
• QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持
  • QUIC连接不以4要素作为标识，而是使用一组Connection ID(连接ID）来标识一个连接
  • 即使IP或者端口发生变化，只要Connection lD没有变化，那么连接依然可以维持
• 比如
  • 当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
  • 当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接

HTTP/3的问题 - 操作系统内核、CPU负载

• 据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量
• Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
• TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在

ARP

• ARP (Address Resolution Protocol)，译为:地址解析协议
  • 通过lP地址获取MAC地址
• RARP (Reverse Address Resolution Protocol)，译为:逆地址解析协议
  • 使用与ARP相同的报头结构
  • 作用与ARP相反，用于将MAC地址转换为lIP地址
  • 后来被BOOTP、DHCP所取代（可以理解为BOOTP是RARP的升级，DHCP是BOOTP的升级）

ICMP

• ICMP (Internet Control Message Protocol)，译为:互联网控制消息协议
  • lPv4中的ICMP被称作ICMPv4，IPv6中的ICMP则被称作ICMPv6
  • 通常用于返回错误信息
    • 比如TTL值过期、目的不可达
  • ICMP的错误消息总是包括了源数据并返回给发送者

HTTP VS WebSocket

介绍

• 单纯的说Socket其实是一套API，是用来建立网络连接的，由操作系统进行了封装，当然，像java也是有自己的一套Socket API的，如ServiceSocket，一般来讲Socker其实就是说的是网络编程。WebSocket指的是网络协议
• HTTP请求的特点:通信只能由客户端发起。所以，早期很多网站为了实现推送技术，所用的技术都是轮询
• 轮询是指由浏览器每隔一段时间(如每秒)向服务器发出HTTP请求，然后服务器返回最新的数据给客户端
• 为了能更好的节省服务器资源和带宽，并且能够更实时地进行通讯，HTML5规范中出现了WebSocket协议
  

WebSocket

• WebSocket，是基于TCP的支持全双工通信的应用层协议
• 在2011年由IETF标准化为RFC 6455，后由RFC 7936补充规范
• 客户端、服务器，任何一方都可以主动发消息给对方(全双工通信)
• WebSocket的应用场景:
  • 社交订阅、股票基金报价、体育实况更新、多媒体聊天、多玩家游戏等

HTTP和WebSocket对比

• WebSocket和HTTP属于平级关系，都是应用层的协议
  • 其实TCP本身就是支持全双工通信的（客户端、服务器均可主动发消息给对方)
  • 只是HTTP的“请求-应答模式”限制了TCP的能力
• WebSocket使用80 (ws://) .443 (wss://）端口，可以绕过大多数防火墙的限制
  • ws://example.com/wsapi
  • wss://secure.example.com/wsapi
• 与HTTP（是TCP建立的连接）不同的是，WebSocket需要先建立连接（应用层）
  • 这就使得WebSocket成为一种有状态的协议，之后通信时可以省略部分状态信息
  • 而HTTP请求可能需要在每个请求都额外携带状态信息（如身份认证等)

WebSocket - 建立连接

• WebSocket需要借助HTTP协议来建立连接（也叫作握手，Handshake)
• 由客户端（浏览器）主动发出握手请求
  
• Connection 必须设置Upgrade
  • 表示客户端希望连接升级
• Upgrade 必须设置websocket
  • 表示希望升级到WebSocket协议
• Sec-WebSocket-Version
  • 表示支持的Websocket版本
  • IRFC 6455要求使用的版本是13
• Sec-WebSocket-Key是客户端生成的随机字符串，比如例子中的dGhlIHNhbXBsZSBub25jzQ==
• 服务器接收到客户端的Sec-WebSocket-Key后，会进行以下操作
  • 一.Sec-WebSocket-Key加上一个固定的GUID值(258EAFA5-E914-47DA-95CA-C5ABODC85B11)
    • dGhlIHNhbXBsZSBub25jzQ==258EAFA5-E914-47DA-95CA-C5ABODC85B11
  • 二.将一的结果进行SHA-1摘要计算
    • b37a4f2cc0624f1690f64606cf385945b2bec4ea
  • 三.将二的结果进行Hex To Base64编码
    • s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
  • 四.将三的结果做为Sec-WebSocket-Accept响应头的值，返回给客户端
• 如此操作，可以尽量避免普通HTTP请求被误认为WebSocket协议

WebService

• WebService，译为: Web服务，是一种跨编程语言和跨操作系统平台的远程调用技术标准
• WebService使用场景举例
  • 天气预报、手机归属地查询、航班信息查询、物流信息查询等
  • 比如天气预报，是气象局把自己的服务以WebService形式暴露出来，让第三方程序可以调用这些服务功能
• 事实上,WebService完全可以用普通的Web APl取代(比如HTTP +JSON)
• 现在很多企业的开放平台都是直接采用Web API

核心

• SOAP (Simple Object Access Protocol)，译为:简单对象访问协议
• 很多时候，SOAP = HTTP +XML
• WebService使用SOAP协议来封装传递数据
  
• WSDL (Web Services Description Language)，译为: Web服务描述语言
• 一个XML文档，用以描述WebService接口的细节（比如参数、返回值等
• 一般在WebService的URL后面跟上?wsdl获取WSDL信息

RESTful

介绍

• REST的全称是:REpresentational State Transfer
• 译为“表现层状态转移”
• REST是一种互联网软件架构设计风格
• 定义了一组用于创建web服务的约束
• 符合REST架构的web服务，称为RESTful web服务

说明

• URL中使用名词(建议用复数形式)，不使用动词
  • 推荐:/users./users/6
  • 不推荐: /listUsers、/getUser?id=6、/user/list、luser/get?id=6
• 使用HTTP的方法表达动作
  
• 一个资源连接到其他资源，使用子资源的形式
  • GET /users/ 6/cars/88
  • POST /users/8/cars
• API版本化
  • xx.com/v1/users
  • xx.com/v2lusers/66
• 返回JSON格式的数据
• 发生错误时，不要返回200状态码

HTTPDNS

介绍

• HTTPDNS是基于HTTP协议向DNS服务器发送域名解析请求
• 替代了基于DNS协议向运营商Local DNS发起解析请求的传统方式
• 可以避免Local DNS造成的域名劫持和跨网访问问题
• 常用在移动互联网中（比如在Android、iOS开发中)
  

使用

• 市面上已经有现成的解决方案
  • 腾讯云: https://cloud.tencent.com/product/httpdns
  • 阿里云: https://help.aliyun.com/product/30100.html
• 移动端集成相关的SDK即可使用HTTPDNS服务

FTP

介绍

• FTP(File Transport Protocol)，译为:文件传输协议，RFC 959定义了此规范，是基于TCP的应用层协议
• 在RFC 1738中有定义，FTP的URL格式为: ftp://[user[:password]@]host[:port]/url-path

连接模式

• FTP有2种连接模式:主动(Active)和被动( Passive)
• 不管是哪种模式，都需要客户端和服务器建立2个连接
  • 控制连接:用于传输状态信息(命令，cmd)
  • 数据连接:用于传输文件和目录信息(data)
    

主动模式

• 客户端打开一个随机的命令端口
  • 端口号大于1024，假设为N
  • 同时连接至服务器的命令端口21
• 客户端开始监听N+1数据端口
  • 同时向服务器发送一个Port命令给服务器的命令端口21
  • 此命令告诉服务器
    • 客户端正在监听的数据端口N+1
    • 并且已准备好从此端口接收数据
• 服务器打开20号数据端口，并且创建和客户端数据端口(N+1)的连接
  

被动模式

• 客户端通过两个随机的端口与服务器建立连接
  • 命令端口N
  • 数据端口N+1
• 客户端的命令端口N用于连接服务器的命令端口21
• 客户端通过命令端口N发送PASV命令给服务器的命令端口21
• 服务器打开一个随机的数据端口P，并告知客户端该端口号P
• 客户端数据端口N+1发起与服务器数据端口P的连接
  

邮件相关的协议

介绍

• 发邮件使用的协议
  • SMTP (Simple Mail Transfer Protocol)，译为:简单邮件传输协议
  • 基于TCP，标准参考RFC 5321
  • 服务器默认使用25端口，SSL/TLS使用465端口

• 收邮件使用的协议
  • POP (Post Office Protocol)，译为:邮局协议
  • 基于TCP，最新版是POP3，标准参考RFC 1939
  • 服务器默认使用110端口，SSL/TLS使用995端口
• IMAP (Internet Message Access Protocol)，译为:因特网信息访问协议
  • 基于TCP，最新版是IMAP4，标准参考RFC 3501
  • IMAP (Internet Message Access Protocol)，译为:因特网信息访问协议基于TCP，最新版是IMAP4，标准参考RFC 3501

收发邮件过程

POP和IMAP

• POP的特点
  • 客户端连接服务器时，将会从服务器下载所有邮件
  • 可以设置下载完后，立即或一段时间后删除服务器邮件
  • 客户端的操作（比如删除邮件、移动到文件夹)不会跟服务器同步
  • 每个客户端都是独立的，都可以获得其自己的电子邮件副本
• IMAP的特点
  • 客户端连接服务器时，获取的是服务器上邮件的基本信息，并不会下载邮件
  • 等打开邮件时，才开始下载邮件
  • 客户端的操作（比如删除邮件、移动到文件夹)会跟服务器同步
  • 所有客户端始终会看到相同的邮件和相同的文件夹

VPN

介绍

• VPN (Virtual Private Network)，译为:虚拟私人网络
• 它可以在公共网络上建立专用网络，进行加密通讯
  
  

作用

• 提高上网的安全性
• 保护公司内部资料
• 隐藏上网者的身份
• 突破网站的地域限制
  • 有些网站针对不同地区的用户展示不同的内容
• 突破网络封锁
• 因为有GWF的限制，有些网站在国内上不了
• Great Firewall of China
• 中国长城防火墙

VPN和代理的区别

• 软件
  • VPN一般需要安装VPN客户端软件
  • 代理不需要安装额外的软件

• 安全性
  • VPN默认会对数据进行加密
  • 代理默认不会对数据进行加密（数据最终是否加密取决于使用的协议本身)
• 费用
  • 一般情况下，VPN比代理贵一般情况下，VPN比代理贵

实现原理

• VPN的实现原理是:使用了隧道协议(Tunneling Protocol)
• 常见的VPN隧道协议有（一般工作在传输层或者数据链路层）
  • PPTP (Point to Point Tunneling Protocol) :点对点隧道协议
  • L2TP (Layer Two Tunneling Protocol) :第二层隧道协议
  • lPsec (Internet Protocol Security) :互联网安全协议sSL VPN (如OpenVPN)

网络爬虫 - robots.txt

无线网络

缓存

介绍

• 实际上，HTTP的缓存机制远远比上图的流程要复杂
• 通常会缓存的情况是:GET请求＋静态资源（比如HTML、CSS、JS、图片等)

缓存 - 响应头

• Pragma: 作用类似于Cache-Control，HTTP/1.0的产物
• Expires:缓存的过期时间(GMT格式时间)，HTTP/1.0的产物
• Cache-Control:设置缓存策略
  • no-storage:不缓存数据到本地
  • public:允许用户、代理服务器缓存数据到本地
  • private:只允许用户缓存数据到本地
  • max-age:缓存的有效时间(多长时间不过期)，单位秒
  • no-cache:每次需要发请求给服务器询问缓存是否有变化，再来决定如何使用缓存
• 优先级: Pragma > Cache-Control > Expires
• Last-Modified:资源的最后一次修改时间
• ETag:资源的唯一标识(根据文件内容计算出来的摘要值)
• 优先级:ETag > Last-Modified

缓存 - 请求头

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

对比

• Last-Modified的缺陷
  • 只能精确到秒级别，如果资源在1秒内被修改了，客户端将无法获取最新的资源数据
  • 如果某些资源被修改了(最后一次修改时间发生了变化)，但是内容并没有任何变化
  • 会导致相同数据重复传输，没有使用到缓存
• ETag可以办到
  • 只要资源的内容没有变化，就不会重复传输资源数据
  • 只要资源的内容发生了变化，就会返回最新的资源数据给客户端

使用流程

IPV6

介绍

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

地址格式

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

首部格式

• 有40字节的固定首部

• Version (占4bit，0110):版本号
• Traffic Class (占8bit) :交通类别
  • 指示数据包的类别或优先级，可以帮助路由器根据数据包的优先级处理流量
  • 如果路由器发生拥塞，则优先级最低的数据包将被丢弃
• Payload Length (占16bit) :有效负载长度
  • 最大值65535字节
  • 包括了扩展头部、上层（传输层）数据的长度
• Hop Limit (占8bit) :跳数限制与IPv4数据包中的TTL相同
• Source Address (占128bit) :源IPv6地址
• Destination Address (占128bit) :目的IPv6地址
• Flow Label (占20bit):流标签
  • 指示数据包属于哪个特定序列(流)
  • 用数据包的源地址、目的地址、流标签标识一个流

扩展头部

• Next Header (占8bit) : 下一个头部
• 指示扩展头部(如果存在)的类型、上层数据包的协议类型（例如TCP、UDP、ICMPv6)

即时通讯

介绍

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

XMPP

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

MQTT

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

• 发布者:客户端
• 代理:服务器
• 订阅者:客户端

流媒体

介绍

• 流媒体(Streaming Media)，又叫流式媒体
  • 是指将一连串的多媒体数据压缩后，经过互联网分段发送数据，在互联网上即时传输影音以供观赏的一种技术
  • 此技术使得资料数据包得以像流水一样发送，不使用此技术，就必须在使用前下载整个媒体文件

常见协议

• RTP (Real-Time Transport Protocol)，译为:实时传输协议
  • 参考:RFC 3550、RFC 3551，基于UDP
• RTCP (Real-Time Transport Control Protocol)，译为:实时传输控制协议
  • 参考:RFC 3550，基于UDP，使用RTP的下一个端口
• RTSP (Real-Time Streaming Protocol)，译为:实时流协议
  • 参考:RFC 7820，基于TCP、UDP的554端口
• RTMP (Real-Time Messaging Protocol)，译为:实时消息传输协议，由Adobe公司出品
  • 默认基于TCP的1935端口
• HLS (HTTP Live Streaming)，基于HTTP的流媒体网络传输协议，苹果公司出品，参考:RFC 8216