| |
|
开发:
C++知识库
Java知识库
JavaScript
Python
PHP知识库
人工智能
区块链
大数据
移动开发
嵌入式
开发工具
数据结构与算法
开发测试
游戏开发
网络协议
系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程 数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁 |
-> 网络协议 -> Linux网络基础3(传输层---TCP/UDP) -> 正文阅读 |
|
[网络协议]Linux网络基础3(传输层---TCP/UDP) |
传输层:负责应用程序之间的数据传输---TCP/UDP UDP: ????????协议实现: ???????? ????????????????16位源端-对端端口:用于描述识别通信两端进程 ????????????????16位数据报长度:能够存储最大数字65535---udp报文总大小最大不能超过64k ????????????????16位校验和:采用二进制反码求和算法---校验接收方接收到的数据与发送方发送的数据是否一致 ????????协议特性: ? ? ? ????????? 无连接:通信时不需要建立连接,只要知道对方地址就可以直接发送数据 ? ? ? ? ? ? ? ? 不可靠:不保证数据安全、有序到达对端 ? ? ? ? ? ? ? ? 面向数据报:无连接的、不可靠的、无序的、有最大长度限制的传输方式 ? ? ? ? 1.udp传输时,sendto发送的数据会被放到发送缓冲区中,而udp协议并不会等待,而是直接对数据封装头部,进行发送 ????????2.udp传输时,收到的数据会被放到接收缓冲区中,而udp保证数据是整条交付,不会出现半条或者多条交付 ? ? ? ? 编程影响: ? ? ? ? ? ? ? ? 1.不保证安全到达:需要在应用层到时候使用tcp所使用的一些机制实现 ? ? ? ? ? ? ? ? 2.不保证有序到达:需要在应用层进行包序管理 ? ? ? ? ? ? ? ? 3.udp报文有最大长度限制:报文最大长度小于64k,因此发送大块数据的时候,需要在应用层进行数据分包再进行发送 ? ? ? ? ? ? ? ? 4.udp实现的是整条交付:因此接收方必须定义的缓冲区足够大,能够一次性取出一条数据 TCP: ? ? ? ? 协议实现: ???????? ????????????????16位源端-对端端口:描述识别两端 ????????????????32位序号-确认序号:进行包序管理 ? ? ? ? ????????4位头部长度:以4字节为单位,表示tcp头部最大有60字节,最小有20字节 ? ? ? ? ????????6位保留 ? ? ? ? ????????6位标志位:URG/ACK/PSH/RST/SYN/FIN ? ? ? ? ????????16位窗口大小:实现滑动窗口机制---流量控制 ? ? ? ? ????????16位校验和:校验接收的数据与发送的数据是否一致 ? ? ? ? ????????16位紧急指针:了解一下带外数据 ? ? ? ? ? ? ? ? 0~40字节选项数据:MSS---Maximum Segment Size,最大报文段长度 ? ? ? ? 协议特性:面向连接,可靠传输,面向字节流 ? ? ? ? ? ? ? ? 面向连接:连接管理+状态管理 ? ? ? ? ? ? ? ? tcp的三次握手建立连接与四次挥手断开连接的过程: ? ? ? ? ? 1.为什么握手时三次,而挥手是四次? ? ? ? ? ? ? ? ? 握手两次不安全,四次没必要。tcp是一个全双工通信,两端都必须确认对方是否具有数据收发的能力 ? ? ? ? ? ? ? ? fin包只能表示对方不再发送数据了,不代表对方不再接收数据了。因此被动关闭方有可能还会继续发送数据,在这种情况下就不能直接发送fin包,而是等待上层用户不再发送数据了,再调用close或者shutdown才会发送fin包,因此被动关闭方的ack和fin并不是一起发送的。 ? ? ? ? 2.tcp三次握手失败了,两端是如何处理的? ????????????????客户端重发syn请求 ? ? ? ? ? ? ? ? 服务端回复ack+syn后,如果超时得不到ack回复,则会发送rst重置连接报文,然后释放新建套接字。 ? ? ? ? 3.TIME_WAIT有什么用? ? ? ? ? ? ? ? ? TIME_WAIT是主动关闭方在断开连接过程中进行最后一次ack回复后进入的状态。如果主动关闭方回复最后一次ack后直接释放资源,就有可能导致在新的客户端中启动套接字使用原来的这个地址信息,而如果上次ack丢失的情况下被动关闭方没有收到回复则会重传fin,因此新客户端收到重传的fin会对新建连接造成影响,并且新客户端发送的syn也会受到影响。 ? ? ? ? ? ? ? ? TIME_WAIT更多的是为了保护客户端启动不会因为使用刚关闭的套接字地址信息,而受到上个套接字的通信遗留问题影响。 ? ? ? ? ? ? ? ? TIME_WAIT等待2个MSL(Maximum Segment Lifetime,表示TCP报文的最大生存时间,系统中默认为60s)时间之后,释放资源,等待两个MSL是为了保证能够对重传的fin进行处理,以及保证本次通信的所有数据都消失在网络中不会对新的连接造成影响。 ? ? ? ? 4.一台主机上出现了大量的TIME_WAIT是什么原因?如何解决? ? ? ? ? ? ? ? ? TIME_WAIT是套接字主动关闭连接,最终进入的状态。因此一台主机出现大量TIME_WAIT意味着大量的主动关闭了套接字 ? ? ? ? ? ? ? ? 解决方法: ? ? ? ? ? ? ? ? ? ? ? ? a.减少TIME_WAIT等待时间 ? ? ? ? ? ? ? ? ? ? ? ? b.使用套接字选项:地址复用(主要在服务端使用) ? ? ? ? ? ? ? ? ? ? ? ? ????????int setsockopt(int fd, int level, int optname, void* optval, int optlen) ? ? ? ? ? ? ? ? ? ? ? ? ????????level:SOL_SOCKET;optname:SO_REUSEADDR---地址重用 ? ? ? ? 5.一台主机上出现了大量的CLOSE_WAIT是什么原因?如何解决? ? ? ? ? ? ? ? ? CLOSE_WAIT是被动关闭方在收到fin包进行ack回复之后所进入的状态,这个状态是等待上层用户调用close/shutdown(WR)后发送fin包的一个状态。 ? ? ? ? ? ? ? ? 如果主机上出现了大量的CLOSE_WAIT的连接,那么意味着可能在代码中没有关闭套接字。 ? ? ? ????????? tcp连接保活机制:通信两端在长时间没有数据通信的情况下,服务端会每隔一段时间向客户端发送一个保活探测数据包(要求对方进行回复),若连续多次没有回复,则认为连接已经断开。(系统默认7200s,每隔75s,9次无回复。这些数值是可以通过设置套接字选项进行设置的。) ? ? ? ? ????????连接断开对于程序的影响:recv返回0,send会触发SIGPIPE异常。 ???????? ? ? ? ? ? ? ? ? 可靠传输:保证数据有序,安全到达对端 ? ? ? ? ? ? ? ? ? ? ? ? 1.面向连接 ? ? ? ? ? ? ? ? ? ? ? ? 2.协议字段中的序号与确认序号,进行包序管理,实现有序传输 ? ? ? ? ? ? ? ? ? ? ? ? 3.确认应答机制:接收方针对收到的每一条数据进行确认回复 ? ? ? ? ? ? ? ? ? ? ? ? 4.超时重传机制:发送数据等待超时无回复后,则认为数据丢失进行重传 ? ? ? ? ? ? ? ? ? ? ? ? 5.协议字段的校验和字段:校验数据一致性,不一致则丢弃,发送重传请求 ? ? ? ? ? ? ? ? ? ? ? ? 6.避免丢包 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? a.发送方发送数据过快过多,使得接收方接收缓冲区满溢导致丢包 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 解决方案:滑动窗口机制---进行流量控制(主要依赖协议字段中的窗口大小字段实现) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 实现原理:告诉发送方最多再发送多少数据,每一方都会有一个接收窗口与发送窗口 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 发送窗口: ????????????????????????????????????????后沿:发送起始序号? ? ? ? 前沿:结束发送位置 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 前沿减去后沿不能大于对方窗口大小 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 接收窗口: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 后沿:起始接收序号? ? ? ? 前沿:结束接收序号 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 前沿减去后沿不能大于剩余空间大小 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 停等协议:收到确认回复后才会发送下一条 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 回退n步协议:从丢失的数据开始进行重新传输 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 选择重传协议:哪条丢了就重传哪条 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? b.传输过程中,网络状态突然不好,导致大量丢包重传 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 解决方案:拥塞机制---以慢启动快增长的形式进行传输 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 实现原理:发送方维护一个拥塞窗口,用于限制当前所能发送的数据大小,而这个拥塞窗口以指数层级增长,实现网络探测,防止传输过程中网络状态突然变差继续大量发送导致的大量丢包。 ? ? ? ? ? ? ? ? ? ? ? ? 7.性能的提升:避免无谓的一些性能损失 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 确认序号:是告诉发送方确认序号之前的所有数据都已经接收成功,避免因为中间的某个确认回复丢失而导致的重传 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 快速重传机制:接收方在接收数据时,先接收到了后发的数据,则认为前边的数据有可能丢失,所以连续间隔发送三条前边数据的重传请求(确认序号为丢失的数据起始序号),发送方收到连续三条重传请求,则对对应确认序号的数据进行重传。主要目的是为了减少超时等待时间,三条重传请求是为了防止数据延迟到达的情况 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 延迟应答机制:接收方接收到数据后,延迟确认回复。接收方接受数据后如果立即进行回复,大概率窗口大小都会变小,延迟应答是为了在延迟期间上层有可能将数据取出,尽量保证窗口大小,保证传输吞吐量。 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 捎带应答机制:将确认回复的信息放到即将要发送的数据报头中,捎带一块传输给对方。尽可能减少纯报头的确认回复(一个报头至少20字节) ? ? ? ? ? ? ? ? tcp如何实现可靠传输: ? ? ? ? ? ? ? ? ? ? ? ? 1.可靠传输:面向连接,包序管理,确认应答,超时重传,校验和 ? ? ? ? ? ? ? ? ? ? ? ? 2.避免丢包:滑动窗口,拥塞机制 ? ? ? ? ? ? ? ? ? ? ? ? 3.提高性能:延迟应答,捎带应答,延迟发送... ? ? ? ? ? ? ? ? udp如何实现可靠传输:在应用层通过tcp实现可靠传输的机制来实现 ? ? ? ? ? ? ? ?面向字节流:基于连接,可靠的,有序的,双向的一种字节流(以字节为单位)传输方式。tcp要发送的数据都会被放到发送缓冲区中,通信时tcp会从缓冲区中取出合适大小的数据(不大于MSS---Maximum Segment Size,最大报文段长度),封装头部进行发送。 ? ? ? ? ? ? ? ? 不限制上层的发送以及接收数据大小,数据会在缓冲区堆积 ? ? ? ? ? ? ? ? 好处:传输比较灵活 ? ? ? ? ? ? ? ? 坏处:会产生粘包问题---将多条数据当作一条进行处理,无法分辨数据边界 ? ? ? ? ? ? ? ? 本质原因:tcp并不维护数据边界 ? ? ? ? ? ? ? ? 解决方案:需要程序员在应用层进行数据边界管理,区分数据边界 ? ? ? ? ? ? ? ? 具体技术:特殊字符,数据定长,在应用层头部加上数据长度字段 ? ? ? ? ? ? ? ? udp不存在粘包问题 |
|
网络协议 最新文章 |
使用Easyswoole 搭建简单的Websoket服务 |
常见的数据通信方式有哪些? |
Openssl 1024bit RSA算法---公私钥获取和处 |
HTTPS协议的密钥交换流程 |
《小白WEB安全入门》03. 漏洞篇 |
HttpRunner4.x 安装与使用 |
2021-07-04 |
手写RPC学习笔记 |
K8S高可用版本部署 |
mySQL计算IP地址范围 |
|
上一篇文章 下一篇文章 查看所有文章 |
|
开发:
C++知识库
Java知识库
JavaScript
Python
PHP知识库
人工智能
区块链
大数据
移动开发
嵌入式
开发工具
数据结构与算法
开发测试
游戏开发
网络协议
系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程 数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁 |
360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年11日历 | -2024/11/26 0:23:56- |
|
网站联系: qq:121756557 email:121756557@qq.com IT数码 |