【Linux 网络编程4】网络层--UDP/TCP协议,3次握手4次挥手、粘包问题等

netstat命令

-n.拒绝显示别名，能显示数字的全部转化成数字(IP+PORT)

-l 仅列出有在 Listen (监听) 的服务的状态

-p 显示建立相关链接的程序名（pid）

-t 仅显示tcp相关选项

-u 仅显示udp相关选项

2.UDP协议

2.1.全双工和半双工的区别

全双工：可以双方同时传输数据，UDP协议和TCP都是全双工
半双工：一次只能一方传输数据；

2.2.UDP的特点

1.无连接：知道对端的IP和端口号就直接进行传输, 不需要建立连接；
2.不可靠：没有应答机制和重传机制；
3.面向数据报：不能够灵活的控制读写数据的次数和数量；
1.必须接受一个完整的报文，不能分两次接受半个报文在拼接；
2.UDP一次只能发送2^16个字节大小的数据，如果超过只能在应用层拆分，再在对端的应用层合并；

2.3.UDP协议格式

16位源端口号：发送端端口号
16位目的端口号：接受端端口号
16位UDP长度：UDP首部（UDP报头）+UDP数据（UDP有效载荷）；整个数据报的总长度
16位UDP检验和：如果校验和出错, 就会直接丢弃；

2.4.UDP的缓冲区

过程：调用系统接口read把缓冲区的数据拷贝到应用层，write直接向内核交付数据

UDP协议只有接受缓冲区：因为没有重传机制和应答机制；

3.TCP协议

3.1.tcp协议格式

16位源端口号：发送端端口号
16位目的端口号：接受端端口号

3.2.首部长度和序号

TCP的报头标长是20字节；

4位首部长度：4个比特位可以表示0-15；报头长度=首部长度*4；所以最大的报头为4*最大首部长度（15）=60；报头长度在20-60可以被4整除的数；

序号：每个报文都会被设置一个序号；一个报文在发送缓冲区最大那一个下标，下面这个报文的序号是1000；

确定序号：表示确定序号之前的序号对应的报文被对端接受了；例：确定序号101，表示101序号以前的序号对应的报文都被接受了，下次使用101序号传输；

3.3.确认应答机制

收到确定报文表示确认序号以前的序号已经被接收；并且确定报文中16位窗口大小被设置表示接收端的接受缓冲区还有多少空间，

如果没收到确定报文，发送端默认对端没有收到将重传；

3.4.TCP协议的缓冲区

TCP协议有两个缓冲区：发送缓冲区和接受缓冲区

过程：调用read实际就是把数据拷贝到发送缓冲区，write把数据从接受缓冲区拷贝到应用层
特点：
1. 效率提高，因为应用层把数据拷贝到发送缓冲区就结束了就返回；
2. 应用层和传输层的解耦，因为应用层把数据拷贝到发送缓冲区，数据就不用应用层管理

3.5.六位标志位

标志位的概念：用于区分不同的报文，确定报文、连接报文等等；

一个标志是3个英文字母总共3字节，有6位的标志位有6字节，所以一次最多设置2个标志，也可以一个都不设置；

6个标志：

前4个标志在3次握手4次挥手讲

ACK: 设置与否表示确认序号是否有效
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段 FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段 RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
URG: 紧急指针是否有效 PSH: 接收端的接收缓冲区快满了发送端没法传输数据了,提示接收端应用程序立刻从TCP缓冲区把数据读走；

URG（不是很重要）：优先先读URG报文不用按序到达，只会读被紧急指针下标的那个字节

3.6.超时重传机制

TCP协议会统计正常通信的时间；来设置一个超时重传的时间

3.7.TCP3次握手，为什么是3次

3次握手过程

3.7.1.第一个原因：3次握手是最小次数，可证明全双工的双端的网络通信信道是正常

3.7.1第二个原因：防止SYN洪水；

1/2握手server端会先于client端建立连接；

那么client端可以无消耗让server建立一个与client的连接并管理起来（消耗server资源）；

3.8.TCP的4次挥手及TIME_WAIT的解释

3.8.1.TIME_WAIT为什么要有这个状态

不能直接CLOSED因为还有给对端发送ACK；

3.8.2.TIME_WAIT需要等多久呢？为什么？

等待时间：需要等2倍MSL时间；

MSL（maximum segment lifetime）时间:MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s,并且TCP协议也有自己的一套方法，统计多个正常一次通信的时间，取最大的一个做MSL；

为什么是2MSL

一个来回是2MSL，ACK没被接受就会重发FIN，刚好一个来回的时间2MSL;

2MSL保证历史发的数据在网络中消散：如果server不等待2MSL直接断开，对面没有收到ACK，将会重发FIN，server立马重连收到重发的FIN又会断开不符合我的要求；

3.8.3.CLOSE_WAIT

如果服务器端，在客户端请求关闭连接，服务器端accept的文件描述符不关闭，会在保持CLOSE_WAIT状态（文件描述符泄漏）

服务器端：只能accept的文件描述符但是不处理

int main()
{
    int listen_sock=socket(AF_INET,SOCK_STREAM,0);
    //bind服务器
    struct sockaddr_in local;
    local.sin_family=AF_INET;
    local.sin_port=htons(PORT);
    local.sin_addr.s_addr=INADDR_ANY;
    bind(listen_sock,(struct sockaddr*)&local,sizeof(local))

    listen(listen_sock,5);

    struct sockaddr_in tmp;
    socklen_t tlen=sizeof(tmp);
    //建立连接
    int fd=accept(listen_sock,(struct sockaddr*)&tmp,&tlen);
}