TCP/IP协议栈

OSI七层模型

实现网络行业的兼容性

• 应用层

  为用户提供接口/interface

  应用层协议: OICQ,HTTP,HTTPS,BT/P2P

  qq底层协议为OICQ

• 表示层

  呈现用户数据 (数据格式，数据加密)

• 会话层

  会话管理(建立，维持，关闭，区分)

• 运输层

  实现数据的可靠/不可靠传输

  运输层协议: TCP UDP(QQ)

• 网络层

  提供三层寻址/IP地址和三层通信(路由器)功能

  IP协议

  ipconfig可查看本机IP地址

• 数据链路层

  提供二层寻址/MAC地址和二层通信(交换机)功能

• 物理层

  提供通信介质和接口标准

OSI实现过程

OSI数据封装与解封装

Ethernet协议

以太网协议，用于实现链路层的数据传输和地址封装(MAC)

三个字段

destination： 目的MAC地址

source: 发送端MAC地址

Type: 上层协议

MAC地址

• MAC地址的前半部分”OUI代码”厂商唯一标识符

全球唯一的48bit的物理地址

冒号分16进制表示

IP协议

互联网协议，用于实现网络层的不可靠的面向无连接的分组传输

组成

…

区分服务/服务质量 1byte

• DSCP

TTL生存时间 1byte

本质是为了解决IP数据报的“环路问题”!

占据带宽，cpu资源

协议

运输层的端口号，链路层的type类型值，网络层的协议，使上层协议能选择适当的协议解封装

首部校验和

让接收方验证此数据报是否完成或发生改动

分片

标识: ID从属的进程

标志: 保留位+DF位置+MF位

片偏移: 8byte为单位的分片数据部分在原分组中距离首部的偏移量

…

ARP协议

地址解析协议，用于实现从IP地址到MAC地址的映射，询问目标IP对应的MAC地址

ARP Request

广播请求

ARP Reply

单播回应

ARP 缓存

ARP缓存表基于”后到优先”原则，IP与MAC的地址映射会被后到的映射覆盖

常用命令

arp -a 查看ARP表

arp -d 删除ARP表项

ping IP 测试网络连通性

ARP攻击

中间人拦截

• 断网攻击
• 限速
• 窃取用户隐私

注意:但凡明文传输的应用,都可以被窃取!

底层原理分析

ARP扫描

获取本局域网的所有主机的IP+MAC地址，根据MAC地址中的OUI还可获得品牌信息

ARP欺骗

中间人持续的发送成百上千的ARP欺骗包，即被伪造的ARP回应包

Vmvare虚拟机网卡模式

1. NAT地址翻转模式 允许访问互联网，各虚拟机共享主机的IP地址
2. 桥接模式 允许访问互联网，各虚拟机使用自己的IP地址(存在一个逻辑上的交换机使得为每个虚拟机均分配了一个IP地址)
3. 主机模式 不允许访问互联网

攻击/渗透工具

p2pover,cain

ARP防御

• 网络设备

丢弃ARP欺骗包

原理

DAI-动态ARP检测技术

1. 交换机记录接口与IP地址与MAC地址的映射 port<->MAC<->IP,生成DAI检测表

   DAI检测表的生成

   1. 手工绑定
   2. DHCP侦听生成DHCP侦听表

2. 对每个接口发回的ARP回应根据DAI表判断是否违规，违规则丢弃并进行惩罚!

• 电脑/手机端

ARP防火墙

绑定正确的IP与MAC地址的映射，收到攻击包时不被欺骗

根据网络数据包的特征，自动识别局域网存在的ARP扫描行为和欺骗行为，并做出攻击判断(谁他妈干的，给爷干回去)

ARP双向绑定/静态绑定

静态绑定IP与MAC地址的映射，后到的映射不会更新旧的映射

ICMP协议

网际控制报文协议

运行在运输层协议，服务于IP协议

实现链路连通性测试和链路追踪，实现链路差错报告

协议字段组成

类型值/代码值 8|0请求 0|0回复 区分数据包类型

校验和 数据完整性校验

标识符 用于标志不同的ping进程

序列号 表示在此进程下的第几个包

ICMP协议应用

Ping命令

探测目的主机是否有问题，探测本地到目的主机的延迟

基于ICMP协议的请求和回复来实现

echo request 回显请求

echo imply 回显应答

DDOS攻击

Distribute deny of service / 分布式拒绝服务式攻击

发送海量报文，占用服务器资源，使其无法提供服务

DDOS攻击工具

• LOIC 图形化

• Hping3

Trace route/tracert

利用TTL超时来实现链路追踪，”网络踩点”

TTL值从1开始递增设置，直至到达目的地

通过为请求包设置特殊的TTL值，使得每经过相应路由，因生命期结束各路由将回复包含IP地址信息的超时回应报文

超时回应报文与端口不可达报文格式

ICMP回应报文嵌套请求报文，用于通知发送发哪个请求报文出现了问题

同一条ICMP请求包将发送三次

Windows 链路追踪的实现原理

请求包封装ICMP请求报文(终点回复ICMP应答报文)

Lniux/Unix 链路追踪的实现原理

请求包封装高端口的UDP包(终点将回复端口不可达报文)

端口

运输层使用16bit的端口号来标志一个端口，仅具有本地意义

分类

• 服务器使用的端口号

  • 熟知端口号

    系统端口号，最重要应用程序端口号

  • 登记端口号

    对应于重要应用程序的其他应用程序的端口号

• 客户端使用的端口号

  • 短暂端口号

    动态选择的客户端应用进程端口号，通信结束，端口号不再存在

UDP协议

用户数据报协议，实现面向无连接不可靠的传输层协议

以UDP用户数据报为运输层协议数据单元

一次交付一个完整报文

字段组成 8byte

源端口 2byte

目标端口 2byte

长度 2byte

校验和(检查不止首部的全部数据报的完整性) 2byte

特征

数据报结构整洁

速度快

实时交互(视频流，实时交互，社交)

基于UDP开发的协议

DHCP,DNS,OICQ,TFTP

DNS协议

域名解析协议 port: 53

原理

请求主机 -> DNS域名请求 -> DNS服务器 — Query 域名 -> IP

google: 8.8.8.8 / 8.8.4.4

114.114.114.114

阿里巴巴: 223.5.5.5

DNS服务器 -> DNS回复 -> 请求主机 — Answers IP

DHCP 协议

动态主机配置协议，用于实现对终端设备的动态IP信息分配

先到先得，请求主机使用先到的IP地址作为其IP地址

通过bootp(启动协议)抓包

原理

• DHCP Client -> DHCP Server

  DHCP Discover包，广播探测寻找局域网的DHCP Server

• DHCP Client <- DHCP Server

  DHCP Offer包，用于预回复客户端，告知其即将给的IP地址

• DHCP Client -> DHCP Server

  DHCP Request包，请求IP地址

• DHCP Client <- DHCP Server

  DHCP ACK包，对客户端进行最终的正式确认(将预分配的IP地址移除本地地址池)

协议字段

• DHCP Discover

  

  请求IP的主机使用0.0.0.0作为源IP，表示不知道/无

• DHCP Offer

  

• DHCP Request

  

  此时并未真正获得IP因此源IP仍为0.0.0.0

  相较于Discover包多了Option: (50)选项字段，指定requested IP

• DHCP ACK

  

原因

为什么需要再次请求与确认？

1. DHCP是基于UDP的不可靠协议，包在传输过程中可能存在丢失情况，若仅仅为discover->offer，导致已从DHCP池中已移除的地址未被主机使用，存在地址浪费问题
2. 解决多Server环境下地址冲突问题，因DHCP池中信息不同步，导致已分配的IP被再次分配，导致地址冲突问题

注意:

2. DHCP交互过程中，服务端为67端口，客户端为68端口

不同系统下的差异

Linux/Unix

DHCP的交互过程都是广播包形式来实现的，目的IP采用255.255.255.255

• 保证客户端与服务器一定能收到数据包

• 多DHCP Server局域网下，DHCP池被所有Server共享，为了保持DHCP池同步更新，需要让其他Server知晓DHCP池中某个IP地址已被分配

抗干扰/冲突能力强，不安全

Windows/Mac os

DHCP的交互过程仅 C -> S 都是广播包形式来实现的，目的IP采用255.255.255.255

S -> C 的包认定请求主机的IP就为预分配的IP，目的IP采用预分配的IP

抗干扰/冲突能力弱，安全

常用命令

ipconfig /all 详细查看ip配置信息

ipconfig /release 释放IP地址

ipconfig /renew 重新分配IP地址

Soctet套接字

套接字Socket = IP地址 + 端口号

TCP协议

传输控制协议，是TCP/IP协议栈中算法最大，功能最复杂的协议

面向连接的可靠交付的提供全双工通信的运输层协议

以TCP报文段为运输层协议数据单元

面向字节流而非完整报文

被套接字唯一确定的点对点通信

TCP报文段首部

• 源目端口

• 序号

对TCP传送的每个字节都按序编号

序号字段标识本报文段发送的数据的第一个字节的序号

• 确认号

  期望收到对方下一个报文段的第一个数据字节的序号

  收到确认号为N，则N之前的所有数据均以正确收到

• 数据偏移 (以4byte为计量单位)

  数据起始对于报文段起始的偏移指明TCP报文段首部长度

• 保留

  保留供以后使用

6个控制位

• 紧急URG

  表示具有高传送优先级

• 确认ACK

  连接建立以后所有传送的报文必须将ACK置为1

• 推送PSH

  考虑到缓存，发送方希望缓存即使未满接收方也能立即回复

• 复位RST

  重置位，重新建立连接

• 同步SYN

  连接建立时同步序号

• 终止FIN

  释放连接

• 窗口

  指明现在允许对方发送的数据量

  告知接收方自己的接受窗口大小以便其设置其发送窗口大小

• 校验和

  校验首部与数据的完整性

• 紧急指针

  指明紧急数据的字节数

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

每发送一个分组就停止发送，等待确认

收到确认后再发送下一个分组。

分组和确认需要进行编号

发送方

发送方每发送完一个分组就保留该分组的副本并设置一个超时计时器

指定时间内未收到确认，则重传副本

对于已收到确认信息的分组再次收到确认信息，直接丢弃

接收方

• 分组出现差错

  对出现差错的分组直接丢弃，正确分组回复确认

• 确认丢失

  再次收到分组时丢弃分组并再次发送确认

• 确认迟到

  再次收到分组时丢弃分组并再次发送确认

连续ARQ协议

ARQ协议信道利用率低，因此采用流水线传输，一次传送多个分组

连续发送 + 累积确认

接收方无需对每一个分组进行确认，而只需对按序到达的最后一个分组发送确认

可靠传输

滑动窗口

以单工A -> B为例，实际为全双工通信

发送窗口

组成

使用三个指针来指明发送窗口的状态

-p1: 已发送已确认的字节，需要从发送缓存中删除

p1: 后沿

p2 - p1: 已发送未收到确认

p2: 最后发送的字节的位置

p3 - p2: 允许发送但未发送的字节 (可用窗口)

p3: 前沿

p2-: 不允许发送的数据

原理

1. 有序发送发送窗口内的字节，窗口外的不允许发送
2. 根据接收到的确认将发送窗口后沿前移至确认字节(接收方期望收到的字节)处，并根据返回的窗口值设置发送窗口的大小
3. 若收到的窗口值变小，则前沿后移
4. 若在超时计时器时间内仍未收到确认信息，则重传对应字节
5. 若发送窗口中的字节均已发送,即可用窗口为0，则停止发送，等待确认信息调整发送窗口后继续发发送

接收窗口

已发送且交付给主机的字节将从接受缓存中删除

原理

1. 接受窗口对于接受到的允许接受的数据先暂存到接受窗口中
2. 若有序则将有序字节交付目的主机，接收窗口向后移动对应字节，将接受缓存中的对应字节删除，并向发送方发送下一字节位置的确认
3. 若无序且在接收窗口之内则先将收到的数据暂存于接受窗口中，不发送确认，直到接收到缺漏的字节才发送有序字节对最后一个字节的确认
4. 重复步骤1

SACK 选择确认机制

对于收到的无序且在接收窗口之内字节块，可以将这些字节块的边界信息告知发送方使其不用再重传这些字节块，而只需重传中间缺失的字节块

· but

双方的TCP报文段需要增设SACK选项，用于指明边界

注意:

1. A与B的发送接受窗口大小不总是一样大，因为时间滞后性且发送窗口受拥塞情况的限制
2. TCP要求接收方必须具有累积确认(发送数据时捎带确认信息)或者捎带确认的机制

经典重传机制

正常

ACK(n+1) = Seq(n) + Len(n)

丢包

ACK(n+1) < Seq(n) + Len(n)

​ ↓ ACK(n+1)为第一次丢包处的序号，从此丢包处起即使已传递的后续包仍需重传

Seq(n+1) = ACK(n+1)

选择重传机制

超时重传机制

重传时间的RTO的选择

RTO过大，将导致网络空闲时间过大，使网络传输效率降低

RTO过小，将导致很多没有必要的重传，加重网络负荷

RTO需要略大于往返时间RTT

RTO的计算

RFC6298标准

未发生重传时RTO计算

RTO = RTTS + 4*RTTD

RTTS

加权平均往返时间

RTT因网络影响并不固定，因此RTO无法使用某一次的RTT来作定量计算

RTTS(初始) = RTT

RTTS = (1-a) * 旧RTTS + a * 本次RTT

a = 1 / 8

RTTD

RTT偏差的加权平均

RTTD(初始) = RTT / 2

RTTD = (1-b) * 旧RTTD + b * | 本次RTTS - 本次RTT |

b = 1 / 4

发生重传时的RTO计算

发生重传时若仍采用上述方法计算RTO，则因为发送方可能对收到的确认识别出现差错，导致无法识别该确认为重传的确认信息还是正常传输的延时确认信息，导致RTT的测量出现差错，进而导致RTO不准确导致新的问题

Karn算法

只要报文段重传，不采用RTT样本计算，此次重传不更新RTO

由于超时重传时间无法更新，滞后性导致新的问题，比如往后得传送RTT均大于RTO，此不是一直重传

Karn算法修正

RTTO = 旧RTTO * 2

TCP流量控制

控制发送方的发送速率，使接收方能够稳定接受，否则发送方发送过快，接收方来不及接受，从而造成数据丢失

通过滑动窗口实现流量控制

接收方通过发送TCP报文段的首部窗口位告知发送方可接受的发送窗口大小从而使发送方调整自己的发送窗口

零窗口通知

当接收方无缓存接受数据时，发送的确定报文段rwnd=0时，发送方调整发送窗口为0不再发送数据

此时若没有机制处理，则双方持续等待(发送方等待rwnd!=0的确认调整发送窗口，接收方有缓存时等待发送方的数据)，导致死锁

-

1. 当发送方收到rwnd=0的确认信息后，启动持续计时器，该时间内未收到确认则发送大小为1字节的零窗口通知，并为该通知创建副本和超时重传计时器

2. 接收方无论是否有缓存可接受都必须接受，若返回rwnd=0的确认报文段则持续1，否则打破死锁

TCP拥塞控制

对某一资源的需求大于其所能提供的，则会使得网络出现拥塞，导致网络吞吐量随传输轮次的增大而减小，最终导致网络吞吐量为0

发送方会维护一个cwnd拥塞窗口，该窗口随网络拥塞情况动态变化

ssthresh慢开始门限，当cwnd<ssthresh时采用慢开始算法，cwnd>ssthresh时采用拥塞避免算法，cwnd=ssthresh均可采用

拥塞控制算法

• 慢开始

  cwnd初始值设置为1

  cwnd随传输轮次的增加一次而加倍增加，一般增加2倍

  当cwnd值到达ssthresh慢开始门限时，开始执行拥塞避免算法

  当发送超时重传时，认为网络出现拥塞，将ssthresh值为当前cwnd的一半，cwnd值重新设置为1

• 拥塞避免

  cwnd随传输轮次的增大呈每次加一线性增长

• 快重传

  为了避免部分报文段丢失使发送方认为出现拥塞实际没有出现从而导致网络传输效率下降

  • 接收方不再捎带确认，而是每次收到报文段都对已有序收到的报文段立即发送确认

  发送方连续收到3次对相同报文段的确认，则进行快恢复算法

• 快恢复

  • 当发送发连续收到3次对相同报文段的确认时，将ssthresh和cwnd均置为当前cwnd的一半并开始执行拥塞避免算法

  • 当发送发连续收到3次对相同报文段的确认时，将ssthresh置为当前cwnd的一半，cwnd置为新 ssthresh + 3 并开始执行拥塞避免算法

TCP运输管理

TCP连接建立

三次握手

三握手连接而非二次握手

当TCP连接请求报文因时间延误，发生超时重传并且连接请求延误报文于第一次连接释放时到达TCP服务器，导致TCP进入了连接建立状态，而TCP客户对此次TCP服务器发送的连接确认不予理睬，导致TCP服务器资源浪费

数据传输

TCP释放连接

四次挥手

Time wait的必要性

若服务器最终确认报文发生超时重传，若无TCP客户无时间等待态，则提前关闭连接可能造成不对TCP服务器的最终确认报文响应，导致TCP服务器无法关闭连接

TCP客户故障处理

若建立连接以后TCP客户发生故障，则无法对TCP服务器作出响应

TCP服务器将设置一个保活计时器，每次收到TCP客户发送的数据时便更新并重启保活计时器

若规定时间内未收到响应，则每75s发送一个探测报文，连续10次未收到响应则认为TCP客户发生故障，断开连接

基于TCP的协议

http 80

https 443

ftp 20/21

ssh 22

telnet 23

smtp/pop 25/100

Telnet协议

远程登录协议，用于对设备进行远程管理，基于明文，建议更安全的SSH

telnet 12.0.1.28

telnet route-server.ip.att.net

多路复用

发送方不同的应用进程可以使用同一个运输层协议传送数据

TCP通过端口号port / 套接字Socket 实现多路复用

源目IP + 源目Port + 协议号 = 五元组