2020/01/01 04-TCPIP协议2

**TCP协议报文头部，有6个标记位。每个标记位占1位，分别是：
紧急指针标记位URG
PSH
RST
SYN
ACK
FIN
**

三次握手，第一次握手，SYN=1，其他位都是0
第二次握手，ACK=1，syn=1，既是请求又是回应包
第三次握手，ACK=1

输入no，相当于现在断开，相当于分手

分手需要4个过程，分手有可能是服务器端主动也可能是客户端主动
A向B提出分手 FIN=1 （finish 结束的意思） seq编号=u
A从ESTAB-LISHED 连接状态 切换到fin-wait-1 终止等待1
B收到请求以后返回 ACK=1 （代表分手的请求收到了，可能还有些数据没有传输完，不代表同意），seq***是v
ACK消息传送后，B从ESTAB-LISHED 切换到 close-wait 关闭等待
close-wait过程中就把还未传完的数据传给A
等传送完数据B服务器会发送FIN=1 ACK=1 (代表数据传完，我也同意分手)
B发完FIN之后就会切换到LAST-ACK (最后确认状态）
A在收到B发的ack=1 之后 就切换到FIN -WAIT2 终止等待2
A在收到B的FIN=1（同意分手）之后，就切换到TIME-WAIT时间等待 (等待2倍MSL时间，MSL时间就等于最大数据段生存期，一个MSL等于2个数据包发送给B需要的时间，（等待要发送到B的两倍的时间））就切换成
CLOSED
A在接收B同意FIN=1之后，就返回ACK=1（表示，B的分手请求也收到了），B从last-ack最后确认状态变为closed

为什么要等上2MSL （2倍的数据生存期）
有些数据在传输过程中可能存在路径的问题，先发后到，未避免这样的情况，所以等待时间，确保数据不丢失
（前面数据发送，但是由于网络的原因，比FIN后到，如果FIN先到，立即进入closed，那么先前还没到的数据就接收不了了）
现在ssh建立，准备分手

7客户端主动分手centos7提出分手请求 fin=1 ack=1 seq=121 ack=201

第二次握手，ack=1（确认收到你的分手请求（不代表同意）） 编号seq=201（包编号是201，对方希望我下次发201） ackn=121 确认号（确认你发的120，希望下次发121）
第三次挥手 fin=1（也同意分手） ack=1 seq=201 ackn=122

最后一次挥手同意了只有ACK
有限状态机 FSM
TCP协议的总11种有限状态机状态
closing,(一般断开连接，是先FIN，然后对方ACK，结果可能，回应的直接是下面的FIN，等于通讯双方都想分手，
紧急指针：特殊情况使用
选项和 填充的值 不是每个包必须有的，必须有的是前面20个字节
（至少了解源，目的端口，序号，确认号，6标记位（ack fin syn））
校验位：校验数据有没有问题
窗口：数据的大小，数据报文在传输的时候，数据大小是多少
表示现在允许对方发送的数据量，也就是告诉对方，从报文段的确认号开始允许对方发送的数据量

通讯双方，发一个包确认一个包，是效率偏低的，这样就是 窗口大小是1 window size=1

可以一下子发好几个包，再确认一次就够了
等于发3个包只要确认一次就可以
固定窗口是不显示的，有可能性能有好有坏
所以不是固定的，就有滑动窗口

姑且认为接受者可以接受3个包，就连续发送三个，但是对方接受者性能有限（window size=2）只能接受2个，希望对方窗口大小是2才合理，回应ACK=3，变相告诉对方，下一次发3,1和2是收到了 ，3没收到，也就是告诉对象，窗口只支持2，下一次发消息就是2
现在窗口大小是301，才301个字节，不是固定的，有大有小
窗口大小需要和窗口扩展因子，大小因子乘以408，才表示最终大小
传一个文件看看实际大小

1514数据包帧的最大值
这两个乘起来就是，达到34560字节的时候就确认一次，不是每次都固定确认的
校验位：校验数据有没有问题
报文格式就确定了为什么tcp有这些特性

拥塞控制就是，通讯双方在传输数据的时候，中间的网络设备，有可能比较繁忙，繁忙就需要控制下发送速度（忙，还拼命发数据，最会造成网络拥堵）

有些要优化网络速度，有些企业就调整里数据包格式，比如谷歌就对tcp协议进行了一些修改，让通讯效率大幅提升

会有孤儿链接，客户端发起半关闭以后，未等服务器关闭链接就强行退出了（客户端和服务器端分手，服务端回应ACK，正常还有3,4包发，结果客户端程序关了，也就意味服务器发第三个包分手包的时候，客户端程序关了，没响应，这时候这个链接就成了孤儿链接）
处于wait2的时候，就没有后续了

linux有关于孤儿连接的相关参数

还有一种类似的，在linux内核和windows中，tcp协议有两个队列，
一个队列叫未完成链接队列
一个队列叫完成链接队列
未完成队列：当客户端三次握手，第一次握手建立连接，服务端建立连接，就是未完成队列
完成队列：三次握手。第一次握手后，建立连接，回应数据包，，就建立了完成队列
这个128意思就是，三次握手，第一次请求，接收队列长度最多128，超过128个接接收不了了，黑客想要攻击你的系统，可以发起大量的连接，占用半链接队列，新的用户连接就没用值 了

完成队列的值，也是128，对linux来说太少了，很容易被黑客利用工具攻击

UDP协议

TCP具有可靠，错误检查，还可以建立三次握手，4次挥手，建立连接有可靠步骤，确保数据传输稳定

UDP是非面向连接，不可靠，没有错误检查
UDP没标记位，无状态
不管网络状态好坏直接发送数据，不管你收到不收到
好处：性能高
大部分基于TCP
QQ使用UDP
传文件就是TCP
tcp相对来讲比较安全

局域网一般比较稳定的UDP
没有***，就不知道UDP是具体哪个包，数据包丢失就丢失了，平时视频会议，大部分用的是UDP协议

INternet层相当于OSI模型的网络层

传输层的下一层在TCP协议中是Internet层 ，在osi模型中叫网络层
Internet层也有很多种比如 IP协议(很关键的协议）
Internet protocol IP协议
Internet control message protocol （icmp）Internet控制消息协议 （用来检查网络状态）
ping命令就是用icmp协议实现的、ICMP协议也可以发起黑客攻击
destination host unreachabl 目标主机不可到达
icmp可以判断网络状态

ping都是发一个，对方回一个
-f flood洪水 发送大量的ping ，尽自己所能 ，-s 也可以调整包大小，对方主机可能受到严重的影响
这样一个点代表一个包
arp address resolution protocol 地址解析协议

第一次和对方通讯，并不知道人在哪里，需要ARP广播，找到机器，对方机器需要回应数据包，告诉具体位置，把自己网卡的的MAC地址，回复以后就知道对方MAC了
然后在以太网帧的头部，对方mac地址就写对方的地址，交换机就记录mac地址，就把对一个的口发送出去，其他就不转发了。
下次就不ARP广播了，会在内存中开辟一块内存空间，ARP缓存，下次就不广播了

arp一定是处于三次握手前完成的，是比三次握手更前的一次握手
这个是arp广播到的，缓存表里缓存下来
tcp握手之前，必须经过arp广播拿到对方mac地址
arp工作时基于广播机制，只要你响应我就相信，所以等到的地址有可能是假的（可能有人冒充）
有人假冒A机器的mac地址，就影响了A和T 之间的通讯

如果要在局域网访问百度，ARP广播过不去，首先A先把百度地址的DNS解析出来，假设IP 1.1.1.1，中间由路由器隔开，A就去找网关，把数据报文发送给网关，网关地址16.0.1 ,就ARP广播到172.16.0.1，这时候数据报文变成这样，
源地址和目标地址不变，源mac地址A，目标mac是路由器1接口的MAC

这时候如果有人冒充网关，提供虚假mac地址，别人就把数据发送到B，arp本身就没验证的功能

**反向地址解析协议rarp（把mac地址解析成IP地址）
RARP反向arp，无盘工作站，光有cpu，内存没有硬盘
启动会发一个请求，请给我一个ip地址
我的mac地址是A，需要分配一个IP地址
arp 是知道ip地址分配一个ip地址
dhcp一般都是维护IP地址，ip跟mac地址绑定
A就得到一个IPA，这样就无论什么时候，保证一台主机，无论何时启动，都得到一个固定的IP地址
**
arp缓存表可能就十分钟

windows里的mac地址

如果两台机器发生冲突，该如何去找，地址冲突，linux小工具arping，能看到mac，如果有人地址冲突是可以看到的