目录
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.转摘
iptables 是一个防火墙工具
Linux内核中有一个用户空间(user space)和内核空间(kernel space),iptables工作在用户空间,在内核空间中相对应的是netfilter,iptables给netfilter传递参数,之后netfilter会对传输进来的数据进行过滤,然后通知应用程序取数据
1、iptables -A INPUT -p icmp --type 8 -j REJECT
2、iptables -F
3、iptables -L
作用:
IP层提供点到点的连接 (网络层)
传输层提供端到端的连接 (端口)
两种协议:
tcp: 面向连接,可靠,手续多–》速度慢 --》圆通
udp: 无连接 ,不可靠,手续少–》速度快 --》顺丰
tcp、udp的选择:根据业务的特点,应用层软件的特点;
不同的应用程序监听不同的端口,通过不同的端口号来区别;
经典端口:
nginx:80
mysql:3306
ssh:22
dns:53
TCP(Transmission Control Protocol)--》打电话
传输控制协议
可靠的、面向连接的协议
传输效率低
三次握手,四次断开,四次挥手--》面向连接
可靠的: 计时器: 重传计时器等
传输效率低: 面向连接,总是需要确认
UDP(User Datagram Protocol) --》发短信
用户数据报协议
不可靠的、无连接的服务
传输效率高
传输控制协议(Transmission Control Protocol)
- TCP/IP协议是Internet最基本的协议、Internet国际互联网络的基础,由网络层的IP协议和传输层的TCP协议组成。
- 通俗而言:TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。
tcp特点:面向连接,可靠,手续多 ,传输效率低(类似:打电话)
三次握手,四次断开——》面向连接
面向连接,总是需要确认——》传输效率低
计时器:重传计时器、time_wait等——》可靠
格式 | 含义 | 位数 |
源端口号 | 应用进程对应的端口号 | 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字节
三次握手体现的是tcp面向连接的特点
- 三次握手封装的数据段里是否有源端口和目的端口?
答:有。
0~1023指派给数值端口号,一些应用程序默认的端口,例如web默认端口为80
1024~40151是登记端口号,一些后来需要端口的协议
49152~65535客户暂时使用的端口号,当建立tcp连接时,client会随机产生一个端口- 二次握手是否可以?
不可以,有可能会发生第二次丢包,这样服务器端就不能知道发的数据包是否到达了客户端,不符合tcp可靠传输的特点- tcp传输的过程是怎么样的?答:自己看图总结
MSL:Maximum Segment Lifetime 报文段最大生存时间
防止客户端最后发的确认包在网络上丢掉,导致服务器一直发包。
说明访问服务器的人很多
用户建立连接后没有再次刷新,服务器主动断开
如何处理time-wait过多的情况?
time-wait这段时间可以发挥更大的作用,如果白白等待,浪费了时间和资源
编辑内核文件/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重用和快速回收。
- [root@sc ~]# sysctl -p #查看内核参数
keepalive timeout 65 用于检测长连接,当业务超时时,服务器会主动断开连接
校验和——校验头部封装有没有被篡改,头部封装好后计算一个hash值
确认——不停地确认就代表前面的包都收到了,没有确认就得重传
- 受损伤的数据段
- 丢失的数据段
- 重复的数据段
- 失序的数据段
- 确认的丢失
crowd window 拥塞窗口:指导滑动窗口
拥塞控制主要是四个算法:
1)慢启动;
2)拥塞避免;
3)拥塞发生(快重传)
4)快速恢复
重传计时器 --> 三次握手的时候重新发送一次数据,确保数据可以收到
坚持计时器 --> 每隔一段时间发探测数据包,为了防止零窗口死锁
保活计时器 --> 防止两个TCP之间的连接长时间的空闲
时间等待计时器 --> 连接终止期间使用的,在发送了最后一个ACK后,不立即关闭连接,而是等待一段时间(2MSL),保证被断开的一方能收到确认数据包。
tcp的应用:
telnet 23 :远程控制,明文传输,不安全
ssh 22
http 80
mysql 3306
ftp 21:文件传输协议
dns 53: dns的主从服务器之间的数据传输
SMTP 25 发送邮件
pop3 110 接收邮件
QQ 8000
dns 53 --》域名解析
dhcp 67
ntp 网络时间协议 123
【问题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个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
其他内容:5_计算机网络_iptables-传输层-TCP/UDP-三次握手/四次断开-内核参数调优_这个手刹不太灵儿的博客-CSDN博客
第一张图片:百度安全验证