网络基础

最新推荐文章于 2023-06-16 22:15:31 发布

Lange_Taylor

最新推荐文章于 2023-06-16 22:15:31 发布

阅读量214

点赞数

分类专栏： linux 成长之路

本文链接：https://blog.csdn.net/Lange_Taylor/article/details/97667362

版权

成长之路同时被 3 个专栏收录

141 篇文章 0 订阅

订阅专栏

坚持

72 篇文章 0 订阅

订阅专栏

linux

18 篇文章 0 订阅

订阅专栏

TCP/UDP重要解析:
目的:为了了解底层协议,使得编程得心应手
应用层:负责应用程序之间的数据沟通;

自定制协议:

结构化数据的传输
序列化:
将数据对象按照指定协议组织成为可持久化存储/数据传输的二进制数据格式串
反序列化:
二进制数据串按照指定协议解析出数据对象

知名协议:HTTP

网址-URL:统一资源定位符
http://username:password@server_ip:server_port/path?query_string#idx
http://username:password@www.baidu.com:80/index.html?wd=C%b%2b&ie=utf8#ch
协议名称:用户名:密码@服务器地址:端口/资源路径?查询字符串#片段标识符
query_string:
key=val^key=val
urlencode:
用户提交的数据中若由特殊字符需要进行编码操作—每个字节转换为16进制字符串,为了表明这两个字符经过了编码操作,因此在前面加上%符号进行标识
urldecode:
遇到%符号,则取出紧跟其后的两个字符,第一个字符转换为数字左移四位+第二个字符转换的数字

HTTP协议解析:

首行:
请求首行: 请求方法 URL 协议版本\r\n
请求方法(GET/HEAD/POST/PUT/DELETE) URL 协议版本(0.9/1.0/1.1/2)\r\n
GET/POST:GET请求没有正文,提交的数据放在url中,url长度是有限的;
POST提交的数据保存在正文中
响应首行:协议版本响应状态码(1**/2**/3**/4**/5**) 常见(200/301/302/44/500/502)
状态码描述\r\n/
头部:
key:val\r\nkey: val\r\n 以一个个键值对组成,键值对以key冒号空格val形式组成.并且每个键值对以\r\n作为结尾
Content-Length/Content-Type/Location/Cookie/Transfer-Encoding
chunked_size\r\nchunked_datachunked_size\r\nchunked_data0\r\n\r\n
空行:
用来间隔头部与正文 \r\n
正文:
向服务器提交的数据/服务端响应的数据

简单http协议的实现:

http是应用层协议,在传输层使用tcp协议实现传输,http服务器默认使用80端口
1.搭建tcp服务端程序
2.按照http协议格式,对接收到的数据进行解析(METHOD,URI,VERSION,HEADER,BODY)
3.根据请求URI对请求做出不同处理
4.对客户端进行响应(首行\r\n头部\r\n\r\n正文)
不管客户端发送什么请求,统一响应

<html><body><h1>Hello World</h1></body><html>

传输层:负责端与端之间的数据传输; TCP/UDP

UDP协议:无连接,不可靠,面向数据报
字段信息:16位源端口,16位目的端口,16位数据报长度,16位校验和
16位源/目的端口:实现端与端之间的数据传输
16位校验和: 校验接收的数据与发送数据是否一致(二进制反码求和算法)
16位数据报长度
无连接,不可靠:双方通信,不需要建立连接,只需要知道双方的地址信息就能发送数据
面向数据报:传输层应用层交付数据的时候只能一整条整条的交付
16位数据报长度,标识了一个完整的udp数据报有多长,接收的时候为了避免接收半条数据,导致缓冲区中的数据长度无法标识,导致交付混乱,因此udp只能整条交付
16位数据报长度,决定了udp数据报最大长度不超过64k-8
但是udp无法保证数据有序到达,因此当在应用层进行分包之后,还需要用户在应用层进行包序管理
udp适用场景:对安全性要求并不是特别高但是对实时性要求比较高的场景

       传输层基于UDP实现的应用层协议:DHCP/DNS

TCP协议特性解析:面向连接,可靠传输,面向字节流

协议字段信息:
16位源/目的端口:实现端与端之间的数据传输
32位序号/确认序号:保证tcp数据的有效交付(包序管理)
4位首部长度:tcp报头长度(并不包含数据),以4字节为单位,tcp包头大小范围:20~60字节
6位标志位:URG/ACK/PSH/RAT/SYN/FIN
16位窗口大小:用于实现滑动窗口机制
16位校验和:校验接收的数据与发送的是否一致
16位紧急指针:带外数据
40字节选项数据:用到的时候才会有,意味着tcp报头长度不固定
面向连接:tcp的连接管理:

     TCP在应用层实现的协议:HTTP/FTP

在这里插入图片描述

LISTEN，SYN-SENT，SYN-RECEIVED，ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT和 CLOSED。

各个状态的意义如下：

CLOSED表示没有连接， LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT - 在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED - 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING - 等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；

TCP连接过程是状态的转换，促使发生状态转换的是用户调用：OPEN，SEND，RECEIVE，CLOSE，ABORT和STATUS；传送过来的数据段，特别那些包括以下标记的数据段SYN，ACK，RST和FIN；还有超时，上面所说的都会使TCP状态发生变化

tcp三次握手与四次挥手的流程以及状态变化

三次握手为什是三次
三次握手的建立连接,是为了确保通信双方都具有收发数据的能力
两次握手不安全:状态迁移变化,确保服务端不会为迟到的重复的SYN建立连接,并且服务端不能保证客户端具有收发数据的能力
四次没必要:SYN和ACK只是两个标志位,没必要分成两个报文进行发送

四次挥手为什么四次:

因为被动关闭方,收到FIN请求报文后,立即进行ACK回复,接下来需要等待用户调用close接口进行确认,缓冲区中的数据已经处理完毕/不关心这些数据了,才会向对方发送FIN请求报文得到ACK回复后,则直接释放socket
因此被动关闭方的ACK和FIN不能直接放在一起进行回复

握手失败如何处理:

服务器等待最后一个ACK报文超时后,向客户端回复RST报文,然后关闭释放socket
避免SYN泛洪攻击

TIME_WAIT状态有什么用?

1.假设没有TIME_WAIT直接关闭套接字会出现什么情况
假设最后一次主动关闭方回复的ACK丢失,并使用相同地址信息启动了新的客户端
1.有可能接收到对方重发的FIN请求,对新连接造成影响
2.向被动关闭方发送SYN请求的时候,对方有可能处于LAST_ACK等待最后一次回复,会认为数据中标志信息错误,回复RST重置连接报文,要求重新建立连接,对新连接造成影响
因此要求主动方关闭,不能直接关闭,而是等待一段时间: 2个MSL
1.接收到重发的FIN请求,则进行回复处理
2.等待网络中后续重发的消息都消失在网络当中,不会对后续连接造成影响
MSL:报文的最大生命周期 30s
time_wait状态是为了保护主动关闭方
套接字选项:
int setsockopt(int sockfd,int level,int optname,const vode optval,socklen_t optlen);
int opt = 1;
setsockopt(sockfd,SOL_SOCKET,SO_REUSEADDR,(void)&opt,sizeof(opt));

tcp连接中的保活机制:

通信双方长时间(7200s)没有数据往来,每隔一段时间(75s)则会给对方发送一个保活探测数据包,要求对方进行回复
1.若是收到回复,则认为连接正常
2.若是连续多次(9)请求都没有回复,则认为连接断开
连接断开在程序中的体现:
recv读完所有数据后,不在阻塞(recv默认没有数据则会阻塞),返回0
send会触发异常–SIGPIPE–默认处理方式—退出进程

可靠传输:

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

tcp为了保证可靠传输,牺牲了部分性能,因此想办法要提高性能,并且避免一些没必要的性能损失(因为ack丢失而导致的重传)

序号/确认序号:避免因为ack丢失而导致的重传每一条数据的确认序号,都要保证在这个序号之前的数据都已经安全到达
若第一条数据没有收到,但是收到了第二条数据,则不能对第二条数据进行确认回复
第一条数据的ack丢失,但是收到了第二条数据ack,则认为第一条数据也已经安全传输

滑动窗口机制:

1.流量控制:
通信每次确认回复进行协商窗口大小,告诉发送方,发送的最大数据大小,这个窗口大小不会超过缓冲区中剩余空间大小, 避免发送过快,处理过慢,导致的接收缓冲区数据塞满,而引起的丢包重传

2.快速重传:
当接收方接收到第二条数据,但是没有接收到第一条,则认为第一条有可能丢失,则立即向发送方发送第一条数据的重传请求,并且将这个重传请求,连续发送三次;
发送方连续收到三次重传请求,则对这条数据进行重传
连续三次发送重传请求,是为了避免有可能因为网络阻塞而收到延迟的数据,
a.停等协议 b.回退n步协议 c.选择重传协议
3.拥塞控制:
发送方维护一个拥塞窗口,控制一次发送的数据量,拥塞窗口以慢启动快增长的形式控制传输的数据量,可以避免因为网络状况不好而导致的大量丢包

捎带应答机制:

接收方为每一条收到的数据组织报文,通过报文头部中的确认序号字段中的确认回复,这时候如果刚好有要给对方发送的数据,则将这次的确认回复序号直接放到要发送的这条数据头中,可以节省一条空报文的回复,提高传输效率

延时应答机制:

接收方接收到数据之后,如果立即回复,窗口大小就会降低,导致传输吞吐率降低,降低了发送速度;
这时候如果接收到数据之后,延迟一会进行确认回复,则有可能用户将数据缓冲区中的数据取走,保证传输吞吐率

    提高性能:滑动窗口机制(流量控制,快速重传,拥塞控制), 延迟应答机制,捎带应答机制

字节流服务:

send发送的数据,会先放在socket的发送缓冲区中,然后操作系统选择为合适的时机将数据发送出去
多条小数据融合成一个大包发送出去,可以提高一定的传输性能;
并且接受方,传输层数据的交付也比较灵活,可以一点一点交付,也可以一次性交付所有数据
但是字节流服务会造成数据粘包问题:多条数据在缓冲区中粘连在一起
粘包的本质原因:tcp在传输层对数据的格式边界不敏感,不会替用户区分那条数据从哪开始,到那结束,只关注需要向用户交付多长字节的数据
因此粘包问题的解决方案就是用户在应用层进行数据的边界管理:
1.特殊字符 2. 数据定长 3.不定长数据在应用头中声明数据长度