DNAT（目标地址转换，Destination Network Address Translantion）：修改数据表的目的IP地址
作用（应用环境）：在互联网中发布位于企业局域网内的服务器
在互联网中发布内网的服务器
将一个网络服务器发布出来，让另外的网络能够使用
发布：背后是对内部资源的管控
SNAT和DNAT可以共存
DNAT实验：
- 内网的服务器配置好ip和网关，dns
- 内网的服务器搭建好web服务，启动nginx
- 网关服务器开启路由功能配置好dnat策略
-t nat：指定nat表里操纵
-A prerouting :在这个位置添加一条规则
-i eth0：从eth0接口进入系统
-d ip：目的ip地址
-p tcp –dprot 80：传输层采用tcp协议 同时目的端口是80
-j DNAT:采取DNAT策略
--to-destination 192.168.1.6:修改目的ip为192.168.1.6
netfilter是一个七层
DNAT如何发布内网不同的服务器呢？
使用不同端口号来对应内网不同的ip地址服务器
dnat修改IP包的目的IP地址，还可以修改tcp或者udp的目的端口号
如果不修改端口号的话，进来什么端口出去就是什么端口（所以可以不接端口号）
SNAT:站在用户角度 帮助用户上网
DNAT:站在企业角度 将服务器发布出去
跳板机（堡垒机，中控机）：表示对于外网只开放连接一台机器 通过这个机器再去连接其他机器，保护内部的安全
传输层：
四层（传输层）负载均衡：TCP和UDP 端口号（源端口和目的端口）
TCP:面向连接，可靠，手续多，速度慢
UDP:无连接，不可靠，手续少，速度快
根据业务的特点：也就是应用层软件的特点进行选择（二者必选其一）
OSI是先有模型 可以适用于各种协议栈
TCP/IP是先有协议，后有模型 只适用于TCP/IP网络
IP层实现了点到点的连接 传输层提供了端到端的连接
不同的应用程序监听不同的端口 通过不同的端口号来区别
常见的服务对应的端口号：
nginx 80
mysql 3306
ssh 22
dns 53
QQ 8000
TCP（传输控制协议） 可靠 面向连接 传输效率低 == 打电话
三次握手，四次断开 体现的是面向连接
各种计时器（重传计时器等）体现的是可靠
传输效率低体现在面向连接，总是需要确认
UDP(用户数据报协议) 不可靠 无连接 传输效率高 == 发短信
TCP工作原理：
TCP封装格式：TCP头部封装（IP包头部封装）占20个字节
源端口（发送进程的）（16位 2字节）
目的端口（接收进程的）（16位 2字节）
端口号的范围：0~65535
32位序列号（seq）（自己发送数据打的标识 标识第多少段）
32位确认号（ack）（对发送端的确认信息，告诉发送端这个序号之前的数据段已收到）
6个标志位（ctl）（包括URG ACK PSH PST SYN FIN）:0或1
URG(紧急指针有效位)：数据比较急 优先处理
ACK（确认序列号有效位）：表明数据包包含确认信息
PSH：通知应用程序尽快处理数据，不在缓存中停留
RST:重新建立连接
SYN：同步 请求建立连接
FIN：数据发送完毕，请求断开连接
16位窗口大小（可变）：滑动窗口的大小，指明本地可接受数据的字节数（最大可用是65536）（通过滑动窗口的大小控制来进行TCP的流量控制）
TCP的连接：三次握手
established：建立连接
查看服务器状态：netstat 命令查看
-a:所有
-n：以数字形式显示（否则会以名字形式 需要域名解析）
-p：程序的名字
-l：表示正在监听状态
-u：udp
-t：tcp
显示的字段：协议 Recv-Q Send-Q 访问的本地IP 外部IP 状态 访问的进程
Recv-Q:
established状态时：表示内核空间里的socket队列还有还有多少数据没有被用户空间里的进程取走 说明应用程序非常忙，处理不过来了
listening状态时：表示多少挤压的数据在这里
Send-Q:
establinshed：表示还有多少字节的数据没有被远程主机确认（发送出去的数据包还没有收到确认）
socket （套接字）：一个程序占用IP地址的一个端口号
访问这个套接字就是访问这个程序 是Linux内核创建的
ip地址+端口号 如192.168.133:8080
把socket理解为一个空间 只要这里面有数据 就会通知应用程序来拿
两次握手是否可以？
不可以 因为包可能会丢 得不到回复 可靠性降低
三次握手封装的数据段里包括有源端口和目的端口
TCP头部封装20字节
IP包头部封装20字节
帧头部封装18字节
/etc/services：记录哪一个协议对应哪一个端口（这些端口就是熟知端口和登记的端口）
四次断开：（可以随意一方先断开 如niginx会设立一个最大连接时间）
两个的回复的seq号一样或者不一样都可以
一样的话 A只需要确认一次 不一样的话 也只需要确认后一个就好了
MSL：最大报文生成时间（最大数据传输时间），一般为2分钟（但太长了，可以定义更短一点）
TIME-WAIT：会等待两个最大数据传输时间（在先断开的那一方），理论上最长可以4分钟
为什么要等待两个时间？
因为怕网络不稳定，最后确认第四个的那个包丢了，B得不到回应，就会一直重传第三个包
Nginx服务器TIME_WAIT特别多是什么情况？
- 说明访问量比较大 且用户没有再发起新的请求（没有再点你的网站了，没有看了已经离开了）
（只要建立一条连接通道 无论点开多少个界面发新的请求都是这条通道）
如何尽量处理timewait过多的情况（如何让timewait等待的这段时间发挥更加哒的作用，不然就白白的在等待，浪费了时间和资源）？
让它可以处理新的连接，提升操作系统的性能
当last-ack比较多说明了什么问题？
可能有人攻击我们，变相的消耗我们的资源
TCP流控机制：滑动窗口（win）
TCP流控机制：拥塞控制
Cwnd：拥塞窗口（只是一个值），指导滑动窗口 对设置滑动窗口提供依据
拥塞窗口的值一般与滑动窗口的值相等
拥塞控制四个算法：（始终保持最多的数据在链路中传输）
- 慢启动
- 拥塞避免
- 拥塞发生（快重传）
- 快速恢复
TCP差错控制：
- 校验和（TCP封装里面有16位校验和）：验证TCP头部是否被篡改
- 确认（发包一定要确认）
- 超时（等一段时间没确认就重传）：背后需要各种计时器
计时器：
重传计时器：（为了控制丢失的数据段）
最多重传3次 然后就断开
坚持计时器：防止零窗口死锁
保活计时器：防止两个tcp之间的连接长时间的空闲
时间等待计时器（连接终止时间使用的）=2MSL
在发送了最后一个ACK后，不利己关闭连接，而是等待一段时间，保证能够接收到重复的FIN数据段
TCP的应用（DNS是UDP和TCP都支持）
UDP：
UDP的应用
UDP没有流控机制
UDP只有校验和来提供差错控制（需要上层协议也就是应用层来提供差错控制：例如TFTP协议）