抓包指令

tcpdump -i any port [端口号] -s 0 -w 123.dat

//123.dat  是我们抓包的数据存放在这个文件

tcpdump 执行命令需要root用户

// sz 123.dat 

//将文件传输给windows

UDP协议

udp协议特点：
  无连接,不可靠,面向数据报

udp协议格式

 16位udp长度：保存udp数据报总长度（udp报头+数据）

16位的校验和:为了校验数据在传输过程当中是否失真。发送方会打上校验和，接收方会通过校验和验证

单条udp数据报是不会超过65536字节？

当超过65536字节udp数据报是没有办法传输的,

  解决方法：应用层中超过65536字节的数据进行拆分，拆分成若干个满足65536字节的数据报
再用udp协议进行传输

比若说传输10000字节数据报

分成        [5000数据报A]  [5000数据报B]  


应用层    在应用层看来就是一条数据



传输层  对于udp而言它会认为自己传输了两个数据报，

udp的应用

DNS：域名解析

  DNS ：应用层协议,完成的事情，域名转换为ip地址，传输层使用的协议是udp协议

  DHCP ：动态主机分配协议 ， 谁上网给谁分配ip  传输层也是使用udp协议

  TFTP ：简单文件传输协议

TCP协议

 面向连接

    三次握手

服务端处于监听状态 , 客户端调用connect,才会进入三次握手

三次握手程序员并没有参与，而是客户端与服务端tcp协议进行连接的

    （SYN_SENT）客户端：----->请求建立连接  服务端

 （established）客户端：<----- 发送确认     服务端   SYN_RCVD

                客户端 ----我知道你收到了我的请求连接   服务端 （established）

TCP为啥三次握手才能建立连接

两次不行吗？

状态：

    服务端已经变成了established状态，
    客户端仍然SYN_RCVD状态，它没有认为连接建立了
    因为没有第三次ack，服务端认为它给客户端发送的确认可能丢失，
    必须要客户端返回确认即（我知道你收到了我的连接请求）


  男（请求交往）     -----      我喜欢你，今晚8点约会吧  ----->      女


  男 （连接建立）    <----       我喜欢你too，今晚8点见  ------     （接受交往）女

  男 （连接建立）    -----       我收到了你的回复        ----->      女（连接建立）

包序管理

结论: tcp维护了发送缓冲区和接收缓冲区，send函数发送的内容，
 会先放到tcp的发送缓冲区当中，tcp自己择机发送 
(tcp自己选择发送的时机， 自己选择发送的数据量)。
 recv函数接收的内容， 是从t的接收缓冲区当中进行接收的，
 接收的数量由程序员调用的recv函数的第三次参数决定。

有序是针对应用层而言的,

无论传输层怎样传输,我应用层收到的数据均是有序的

 三次握手当中的包序管理------seq-----ack

研究tcp的序号和确认序号




序号: 发送方发送数据的时候，针对数据的编号期望下一次发送方从那个序号考试发送数据

确认序号: 接收方告诉发送方，引申含义就是: 接受方告诉发送方，确认序号之前的内容都收到了

结论:


tcp维护了丝套序号，客户端维护一套， 服务端维护一套




客户端发送数据的时候使用客户端维护的序号，对于发送的数据进行编号


服务端发送数据的时候，使用服务端维护的序号， 对于服务端发送给客户端的数据进行编号

双发建立连接过程中序号一定要从0号开始

不一定！！！，只要满足后续发送数据，按照之前编号就可以

 ACK数据包不会消耗序号

ack如果占用数据报,


client                        server

对确认进行确认

对确认的确认进行确认

对确认的确认的确认进行确认

.........


在网络传输中传递大量的确认数据包

三次握手的ACK数据包在传输过程当中丢掉了

1.客户端可以给服务端发送数据吗？

    可以，并且发送数据当中ack，是具有确认功能的
 想想--两次握手我们的客户端是认为自己处于连接建立状态的它当然可以给服务端发送数据
  顺带就发送了确认帧


-------------------------------------------------------------------------------------------

2.服务端可以给客户端发送数据码？

    不可以

    但是当客户端给我们服务端发送数据后就可以了

客户端既发送了数据，又完成了三次连接的建立，此时服务端由SYN_RCVD变为established状态  

TCP四次挥手（连接断开）

 经典面试题

客户端先告诉服务端连接断开， 这个时候， 服务端存在大量的TIME_WAIT状态怎么办呢?

客户端由于是先给服务端发送的断开连接请求，所以TIME_WAIT状态不会存在服务端， 而是客户端。


面试官你是想问 客户端存在大量的TIEM_WAIT状态吗? ----》 最终呢， 问题可能归结为服务端先断开,
存在大量TIEM_WAIT状态怎么解决?

下文提供解决方法！！！！

主动断开连接方为什么需要等待2MSL的时间之后，状态才能从TIME_WAIT状态，变迁成为CLOSED状态


为了防止ACK丢失，导致被动断开连接方进行重传FIN如果被动断开连接方重传了之后，
则主动断开连接方需要进行处理，所以在等待（如果确认帧丢失，则被动断开连接方会因为收不到确认帧而无法关掉）




当然， 如果ACK正常传递到了被动断开连接方， 那么被动断开连接方的状态就变成CLOSED状态
主动断开连接方等到2MSL时间之后， 状态从TIME_WAIT变迁为CLOSED状态



MSL:报文最大生存时间， 发送方给接收方发送一个数据， 如果在MSL时间范围内还没有到达接收方，
则认为该数据被网络丢掉了(丢包了)


2MSL = 2个TCP报文的最大生存时间（刚好是一个发送确认帧时间  和 未收到确认帧的被动断开连接方的重新发送Fin的时间）

如果服务端存在大量TIME_WAIT状态，如何快速重启进程?

在2MSL时间内: 程序员自己写的进程，程序员自己写的进程都没有了(崩溃了)?(收到信号退出了)
导致网络协议栈并没有释放刚才服务端占用的端口但是刚才进程占用的端口还在被网络协议栈当中
的TCP协议所占用(2MSL==60秒---对于股票交易是十分致命的)


由于上面的原因， 会引发:如果此时服务端进程想要快速的重启， 重启就意味着要绑定端口， 最终就会导致程序重启的时候报错， 端口被占用




解决当前这个问题:设置端口重用
任务1: setsockopt函数， 如何设置端口重用

TCP格式

16位窗口大小:告诉消息接收方， 自己的接收能力是多少，  单位字节， 动态变化的

16位校验和: 校验数据在发送过程中是否失真

16位紧急指针: 配合URG标志位， 发送带外数据


-----------------------------------------------------------------------------------------


URG : 紧急标志位              当tcp需要发送带外数据的时候，就会设置紧急标志位


ACK : 确认标志位              确认数据的时候，需要设置这个标志位


PSH : 发送数据标志位


RST : 重置连接标志位连接重置


SYN :连接发起标志位


FIN : 断开连接标志位

-----------------------------------------------------------------------------------------


发送方发送数据时是有自己的发送缓冲区的，如果设有URG标志的数据会被直接发送(不用在发送缓冲区当中)
，无需等待在其他数据后

MSS十分重要！！！

为啥要协商最大报文段长度呢?



本质原因:防止报文过大， 再网络当中数据丢失， 引发后续的超时重传机制。



比如你要发一个50000字节的数据包，当你上传完了发送过程，网络过于拥挤数据丢失了
你就要重新传输 50000字节！整整50000字节！！！（就会很浪费时间）

TCP的可靠传输

     可靠：

     确认应答机制：保证数据可靠有序的送达对端

 超时重传机制

超时时间

RTO:超时重传时间
RTO=2RTT

RTT:报文往返时间(报文往返一次的时间)


RTT(预测的下一次时间)=RTT(上一次)*i+RTT(上上次)*（1-i）
i=0.9

TCP就需要考虑传输效率的问题， 考虑传输效率得要从三个方面考虑 

1.提高自身发送数据量。 换句话说，一次性发送的数据越多， 传输的越多
    
    MSS : 决定了一次性传递的数据的上限(这个没有办法修改)

确认应答机制:决定了每一个TCP数据包都是需要确认的 (这个可以打破) 
-------------------------------------------------------------------------------------------

2.对方的接收能力。 换句话说， 对方的接收缓冲区的大小

-------------------------------------------------------------------------------------------

3.网络转发能力。换句话说， 从A主机到B主机的网络链路上的转发设备的负载大不大

提高自身发送数据量

优点: 在不考虑网络的情况下， 可以提高发送数据量。 因为发送的越多， 传输的越多


缺点:需要防备数据丢失的情况， 触发超时重传， 一旦触发超时重传，则数据就需要重新发送过去。 也就是
意味着发送方在没有接收到确认之前， 是需要将数据缓存起来的 (这个就是TCP的发送缓冲区)

滑动窗口大小会发生改变吗？

动态变化的

 滑动窗口丢包的问题

通过对方的接受能力控制传输数据量

延时应答机制

（等待的本质）本质上想让应用程序从缓冲区中拿走数据，好让缓冲区更大一些，发送确认时

告诉发送方我们缓冲区的大小。

-------------------------------------------------------------------------------------------

网络转发能力

拥塞控制三个阶段

TCP当中的计时器