网络知识点总结

OSI七层网络模型:
应用层—>表示层—>会话层—>传输层—>网络层—>链路层—>物理层

TCP/IP五层模型:
应用层—>传输层—>网络层—>链路层—>物理层

应用层:应用程序之间的数据沟通(DNS,URI,HTTP,HTML)
传输层:端与端之间的数据传输(TCP,UDP)
网络层:地址管理和路由选择(IP,ARP)
链路层:相邻设备之间的数据传输
物理层:光电信号的传输

IP地址:
在网络中唯一标识一台主机
协议
IPV4:uint32_t 无符号4字节 32位 的整数
IPV6:uint8_t 无符号16字节128位的整数

端口号(PORT):
端口号用来标识一个进程,告诉操作系统当前数据要交给哪一个进程处理
端口号是一个2字节16位的整数
一个进程可以bind多个端口号，因为一个进程可以打开多个文件描述符，而每一个文件描述符都对应一个端口号
一个端口号不能被多个进程bind，但是如果一个进程先绑定一个端口号，再fork()一个子进程，这可以实现多个进程绑定一个端口号，但是不同的两个进程不行
端口号的划分
0-1023：知名端口号，如ssh(22),ftp(21),http(80),https(443)
1024-65535：操作系统动态分配的端口号
查看网络状态命令—netstat
查看服务器的进程ID—pidof

TCP协议
TCP协议段格式

16位源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去
32位序号/32位确认号：保证TCP数据的有序交付，包序管理
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部大长度是15 * 4 = 60 ，报头的大小范围是20~60字节
6位标志位：URG,ACK(确认)，PSH，RST(复位)，SYN(同步),FIN(结束)
16位窗口大小: 实现滑动窗口机制
16位校验和：检验数据前后的一致性
16位紧急指针：标识紧急数据
40字节头部选项：用到才会有

特点:
1.传输层协议
2.有连接
3.可靠传输
4.面向字节流

TCP可靠传输

1.连接管理
2.确认应答机制
3.超时重传机制
4.协议字段中的序号/确认序号
5.协议字段的校验和

连接管理：三次握手，四次挥手，状态变化

状态变化如上图所示：
三次握手：服务端在未接收到连接请求时一直处于listen状态，客户端请求建立连接，服务端收到连接请求（SYN_RCVD）再向客户端发送建立连接、确认请求，客户端收到后（ESTABLISEHD）再向服务端发送确认请求，连接成功
四次挥手：假设客户端先发起断开连接请求，客户端发送FIN后变为FIN_WAIT1状态，服务端接收到请求后变为CLOSE_WAIT状态，向客户端发送一个ACK的确认信号，客户端收到请求变为FIN_WAIT2状态，服务端变为LAST_ACK状态，延迟一会儿后变为再发一个FIN的请求，客户端变为TIME_WAIT状态，再向服务端发送一个确认断开连接的ACK，服务端接收到后关闭，客户端等待一会儿后也关闭

主动关闭方为什么没有关闭直接释放socket，而是进入TIME_WAIT状态，等待一段时间才关闭？
答：假设主动关闭方直接释放套接字，但是最后一次回复的ACK丢失，有可能会对后续连接造成影响
1.最后一次传的ACK丢失，被动关闭方重传FIN请求报文，主动关闭方重新启动相同地址的客户端，会受到这个报文，造成错误
2.主动关闭方重新以相同地址启动，再向被动关闭方建立连接请求时，可能会遇到状态错误（因为对方一直处于等待ACK状态）
3.等待的一段时间中处理被动关闭方重传的FIN请求报文，等待2MSL时间，确保重传的报文消失在网络中（ps:MSL为报文的最大生命周期）

TCP提高性能的机制

1.滑动窗口（流量控制，快速重传，拥塞控制）
2.延迟应答
3.捎带应答

1.滑动窗口机制：通信双方会通过协议字段中的窗口字段协商窗口大小，告诉对方一次性可以发送的最大数据量，这些数据当然不会一次性全部发送，通信双方通常在三次握手阶段，还会协商一个数据较MSS（最大数据段大小–数据报中数据的最大长度），发送方在发送数据时就会将数据分成多个大小不大于MSS大小的数据报进行发送
流量控制：通过协议字段中的窗口字段，通知发送方能够发送的最大数据量，通过这个来限制对方的发送速度，避免发送过快，导致缓冲区塞满，引起后续数据丢失
快速重传：当接收方收到第二条数据，但是没接收到第一条，则认为第一条可能丢失，这是会向发送方连续三次发送第一条数据的重传请求，发送端接收请求，则将这条数据重传，发三次是为了尽量避免因为网络阻塞而收到延迟的数据
拥塞控制：发送方维护一个拥塞窗口，控制一次发送的数据量，拥塞窗口以慢启动快增长的形式控制传输的数据量，起到对网络进行探测的作用，可以避免因为网络状况不好而导致大量丢包

2.捎带应答机制：接收方每收到一条数据组织报文，都会通过报文头部的确认序号字段进行确认回复，这时如果刚好有给对方发送的数据，则将这次的确认回复序号直接放到要发送的这条数据头中，可以节省一条空报文的回复，提高传输的效率

3.延迟应答机制：接收方如果接收到数据之后立即回复，窗口的大小就会减小，吞吐量降低，降低了发送速度，这时如果收到数据，延迟一会儿进行确认回复，则有可能用户将缓冲区的数据读取走，保证传输吞吐率

TCP中的字节流服务
send发送的数据，会先放到socket的发送缓冲区中，如果发送的字节数太长, 会被拆分成多个TCP的数据包发出; 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者操作系统选择合适的时机将数据发送出去----也就是延迟发送机制
多条小数据荣和城一个大包发送，可以提高一定的传输性能
并且接受方，传输层数据的交付也比较灵活，可以一点一点交付，也可以一次性交付，但是字节流服务会造成数据的粘包问题：多条数据在缓冲区粘连在一起
粘包产生的本质原因：ctp在传输层对数据的格式边界不敏感，只关注需要向用户交付多长字节的数据
粘包问题的解决

粘包问题的解决方案是用户在应用层进行数据的边界管理：
1.特殊字符分隔
2.定长读取
3.在包头的位置约定一个包总长度的字段，从而知道包的结束位置（类似UDP中的报文长度）

注意UDP中不存在粘包问题：如果上层没有交付数据，UDP的报文长度仍然存在，UDP是整条交付，不会出现半条数据的情况

TCP连接管理中的保活机制
通信双方长时间（7200s）没有数据往来，每隔一段时间（75s）就会给对方发送一个保活探测数据包若收到回复，表明连接正常，连续9次不回复，则认为连接断开

连接断开在程序中的体现：recv读完所有数据之后，返回0；send触发异常SIGPIPE

//
UDP协议
UDP协议格式

16位源端口号+16位目的端口号+16位UDP长度+16位UDP检验和+数据

16位数据长度决定了UDP数据报最大长度不超过64k（包含首部）
若sendto发送数据段大小大于64k-8，就需要在应用层手动分包，多次发送，并在接收端手动拼装，否则就会传输失败
6位UDP检验和用来检验接收与发送内容是否一致（二进制反码求和）
而且UDP无法保证数据有序到达，因此分包传输后，还要在应用层进行包序管理
UDP没有真正意义上的 发送缓冲区. 但是UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果 缓冲区满了, 再到达的UDP数据就会被丢弃;
特点:

1.传输层协议
2.无连接：知到对端IP和端口号就可传输，无需连接
3.不可靠传输：没有确认机制，没有重传机制
4.面向数据报：不能灵活控制读取数据的次数和数量，只能整条交付

基于UDP的应用层协议
NFS/DHCP/DNS
//
字节序
CPU在内存中对数据的存取顺序----针对存储大小大于1个字节的数据类型(如int long short double float)
但是字符串本身就是按照字节存储的,直接传输
字节序是由CPU架构决定,x86架构的为小端

网络字节序

发送主机通常将发送缓冲区中的数据按内存地址从低到高的顺序发出;
接收主机把从网络上接到的字节依次保存在接收缓冲区中,也是按内存地址从低到高的顺序保存;
因此,网络数据流的地址应这样规定:先发出的数据是低地址,后发出的数据是高地址.
TCP/IP协议规定,网络数据流应采用大端字节序,即低地址高字节.
不管这台主机是大端机还是小端机, 都会按照这个TCP/IP规定的网络字节序来发送/接收数据; 如果当前发送主机是小端, 就需要先将数据转成大端; 否则就忽略, 直接发送即可;

大端小端的判别

例如：int a=0x01 02 03 04
从左往右地址是由高到低
小端：低地址存低位，在小端中b=(uchar*)&a,则b[0]=04, b[1]=03, b[2]=02, b[3]=01
大端：低地址存高位
主机大小端的识别：
用联合体union{int a=1;uchar b;}
当b=1时，为小端， b=0时为大端

//
HTTP协议
HTTP协议又叫做超文本传输协议

URL（统一资源定位符）----俗称网址
urlencode
将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY 格式
urldecode
urldecode就是urlencode的逆过程

HTTP协议格式
首行：
请求首行：请求方法+URL+协议版本\r\n
请求方法：GET/HEAD/POST/PUT/DELETE
GET：GET请求没有正文，提交的数据放在URLl中，URL长度有限
协议版本：0.9/1.0/1.1/2
响应首行：协议版本+响应状态码+状态码描述
常见响应状态码：

Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个 Content-Length属性来标识Body的长度;

五元组

源IP，目的IP，源端口，目的端口，协议版本