目录

1.iptables

2.传输层

3.tcp协议

3.1、TCP封装格式

3.2、三次握手

3.3、四次断开

3.4、TCP的差错控制

3.5、TCP的拥塞控制

3.6、计时器

 4.UDP协议

5.经典的端口号

 6.学习中的问题

7.转摘



1.iptables

iptables 是一个防火墙工具
Linux内核中有一个用户空间(user space)和内核空间(kernel space),iptables工作在用户空间,在内核空间中相对应的是netfilter,iptables给netfilter传递参数,之后netfilter会对传输进来的数据进行过滤,然后通知应用程序取数据

IPTABLES 实现docker端口转发 iptables转发udp_bash


                                                                    图1

1、iptables -A INPUT -p icmp --type 8 -j REJECT
2、iptables -F
3、iptables -L

2.传输层

作用:

IP层提供点到点的连接 (网络层
传输层提供端到端的连接 (端口)

两种协议:

tcp: 面向连接,可靠,手续多–》速度慢 --》圆通
udp: 无连接 ,不可靠,手续少–》速度快 --》顺丰

tcp、udp的选择:根据业务的特点,应用层软件的特点;
不同的应用程序监听不同的端口,通过不同的端口号来区别;

经典端口:

nginx:80
mysql:3306
ssh:22
dns:53

TCP(Transmission Control Protocol)--》打电话
	传输控制协议
	可靠的、面向连接的协议
	传输效率低

三次握手,四次断开,四次挥手--》面向连接

可靠的: 计时器: 重传计时器等
传输效率低:  面向连接,总是需要确认


UDP(User Datagram Protocol) --》发短信
	用户数据报协议
	不可靠的、无连接的服务
	传输效率高

3.tcp协议

传输控制协议(Transmission Control Protocol)

  • TCP/IP协议是Internet最基本的协议、Internet国际互联网络的基础,由网络层的IP协议和传输层的TCP协议组成。
  • 通俗而言:TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。

tcp特点:面向连接,可靠,手续多 ,传输效率低(类似:打电话)

三次握手,四次断开——》面向连接

面向连接,总是需要确认——》传输效率低

计时器:重传计时器、time_wait等——》可靠

3.1、TCP封装格式

IPTABLES 实现docker端口转发 iptables转发udp_bash_02

格式

含义

位数

源端口号

应用进程对应的端口号

16

目标端口号

目标端接收进程的端口号

16

序列号

给每个发送的数据段进行编号的

32

确认号

告诉对方哪个数据段之前的数据都收到了

32

窗口大小

指定本地可接收数据的字节数

16

校验和

校验头部有没有被篡改

16

紧急指针

配合控制位URG的使用

16

6个控制位

控制位

含义

解释

URG

urgent 紧急位

与16位紧急指针配合使用

ACK

acknowledgement 确认位

1表明该数据包包含确认信息 ,最大2^32-1

PSH

push

通知应用程序尽快处理数据,不要让数据在缓存里停留

RST

reset 重置位

重置,重新连接

SYN

sync 同步位

同步,建立连接

FIN

finish 完成位

请求断开连接

*TCP是怎么进行流量控制的?

通过调整滑动窗口的大小值来进行流量控制的

*TCP头部封装最少占多少位?

  tcp头部封装最少是20位
  ip包头封装是20位
  mac头部封装占64~1518字节

3.2、三次握手

三次握手体现的是tcp面向连接的特点

IPTABLES 实现docker端口转发 iptables转发udp_linux_03

  • 三次握手封装的数据段里是否有源端口和目的端口?
    答:有。
    0~1023指派给数值端口号,一些应用程序默认的端口,例如web默认端口为80
    1024~40151是登记端口号,一些后来需要端口的协议
    49152~65535客户暂时使用的端口号,当建立tcp连接时,client会随机产生一个端口
  • 二次握手是否可以?
    不可以,有可能会发生第二次丢包,这样服务器端就不能知道发的数据包是否到达了客户端,不符合tcp可靠传输的特点
  • tcp传输的过程是怎么样的?答:自己看图总结

3.3、四次断开

IPTABLES 实现docker端口转发 iptables转发udp_网络_04

  • 为什么要等到2MSL?

        MSL:Maximum Segment Lifetime 报文段最大生存时间

        防止客户端最后发的确认包在网络上丢掉,导致服务器一直发包。

  • 服务器 time-wait比较多,是什么原因?
  1. 说明访问服务器的人很多
  2. 用户建立连接后没有再次刷新,服务器主动断开
  • 如何处理time-wait过多的情况?
  1. time-wait这段时间可以发挥更大的作用,如果白白等待,浪费了时间和资源
  2. 编辑内核文件/etc/sysctl.conf,加入以下内容:
    net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
    net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
    net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间
    然后执行sysctl -p 让参数生效.
    /etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口,它包含一些TCP/IP堆栈和虚拟内存系统的高级选项,修改内核参数永久生效。
    简单来说,就是打开系统的TIMEWAIT重用和快速回收。
  1. [root@sc ~]# sysctl -p  #查看内核参数
  • 配置文件中的keepalive timeout 65

        keepalive timeout 65 用于检测长连接,当业务超时时,服务器会主动断开连接

3.4、TCP的差错控制

校验和——校验头部封装有没有被篡改,头部封装好后计算一个hash值
确认——不停地确认就代表前面的包都收到了,没有确认就得重传

  • 受损伤的数据段
  • 丢失的数据段
  • 重复的数据段
  • 失序的数据段
  • 确认的丢失

3.5、TCP的拥塞控制

IPTABLES 实现docker端口转发 iptables转发udp_网络_05

crowd window 拥塞窗口:指导滑动窗口

拥塞控制主要是四个算法:
1)慢启动;
2)拥塞避免;
3)拥塞发生(快重传)
4)快速恢复

3.6、计时器

重传计时器 --> 三次握手的时候重新发送一次数据,确保数据可以收到

IPTABLES 实现docker端口转发 iptables转发udp_linux_06

坚持计时器 --> 每隔一段时间发探测数据包,为了防止零窗口死锁 

IPTABLES 实现docker端口转发 iptables转发udp_网络协议_07

 保活计时器 --> 防止两个TCP之间的连接长时间的空闲

IPTABLES 实现docker端口转发 iptables转发udp_bash_08

 时间等待计时器 --> 连接终止期间使用的,在发送了最后一个ACK后,不立即关闭连接,而是等待一段时间(2MSL),保证被断开的一方能收到确认数据包。

IPTABLES 实现docker端口转发 iptables转发udp_linux_09

 4.UDP协议

  • 用户数据报协议(User Datagram Protocol)
  • udp特点:无连接,不可靠,手续少,传输效率高(类似:发短信)
  • QQ服务器:端口8000,UDP协议

5.经典的端口号

tcp的应用:
telnet 23 :远程控制,明文传输,不安全
ssh 22
http 80
mysql 3306
ftp 21:文件传输协议
dns 53: dns的主从服务器之间的数据传输
SMTP 25 发送邮件
pop3 110 接收邮件

IPTABLES 实现docker端口转发 iptables转发udp_bash_10

 UDP的应用

QQ 8000
dns 53 --》域名解析
dhcp 67
ntp 网络时间协议 123

IPTABLES 实现docker端口转发 iptables转发udp_网络_11

 6.学习中的问题

【问题1】为什么连接的时候是三次握手,关闭的时候却是四次断开?

答:对于三次握手,client端向server端发送SYN请求,server端收到后,server端会发送SYN请求+ACK确认,表示server端也想建立连接,并且告诉client端自己收到了数据包,这两次握手是必不可少的,之后client发送ACK,代表自己收到了server端的数据包,如果这次握手缺少,server端并不能知道自己发送的数据包client是否收到,也就不能保证可靠传输;

对于四次断开,假如server端向client端发起断开,client端可能还要业务没有完成,所以会先给服务器发送ACK,表示自己收到了数据,如果缺少这次断开可能会导致client收到的数据缺失,当自己业务完成后,client端也会向server端发起断开,最后server端回应client端自己收到了数据包

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:上面已给出答案,自己找

【问题3】如果已经建立了连接,但是client端突然出现故障了怎么办?

TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。