bit::Shadow✧(≖ ◡ ≖✿目录传输层端口号六元组端口号端口号范围划分端口号0-1023不是特定端口号吗为什么可以sudo绑定进程与端口号的关系UDP协议内核格式UDP数据加工UDP传输不是“不可靠”吗为什么还有16位校验和呢为什么设计校验和UDP传输的特点面向数据报UDP的缓冲区UDP 使用注意事项基于 UDP 的应用层协议传输层负责数据能够从发送端传输到接收端。端口号每个端口号都代表特定主机下的一个程序。IP代表一个主机六元组当数据从发送端的应用层-传输层-网络层-数据链路层之后得到端口号端口号范围划分【0,1023】固定/知名端口号HTTP, FTP, SSH等的固定的。 像SSH22 HTTP80【1024,65535】操作系统动态分配客户端程序。65536 2^16端口号0-1023不是特定端口号吗为什么可以sudo绑定要回答“为什么是固定的但sudo又能绑定”核心在于区分两个概念端口的使用规则协议规定和端口的绑定权限操作系统规定。简单来说0-1023的固定是“行业规范”而sudo能绑定是“操作系统许可”。规范约束的是软件开发者而许可约束的是系统用户。进程与端口号的关系怎样理解“一个进程可以绑定多个端口号而应该端口号只能绑定一个进程”1.因为一个进程里可以开很多个Socket套接字。进程是“容器”Socket是它的“子工具”。一个Web服务器比如Nginx启动后它可以同时bind(80)用于HTTP同时bind(443)用于HTTPS甚至再bind(8080)做个管理后台。这些端口号在操作系统内核的端口管理表里虽然端口号不同但它们对应的进程IDPID是同一个。2.端口号的设置是程序级设计目的在于标识系统下的唯一性程序。因此“只能绑定一个进程”否则如果有两个进程同时绑定80端口内核就混乱了“这个包到底该给谁”接下来在理解原理部分强调以下注意事项1. 构建立体化视角对于应用层、传输层、网络层。2.基于“应用层”的根基思考网络的层状结构。UDP协议内核格式路径linux-2.6.18\include\linux\udp.hUDP数据加工上部分就是位于传输层的UDP添加的报头。下端是有效载荷16位UDP长度表示自UDP首部UDP数据的最大长度。校验和如果校验和出错数据直接丢弃。UDP传输不是“不可靠”吗为什么还有16位校验和呢分析UDP“不可靠”绝对没错“不可靠”描述的是传输的“送达与否”。因此我们猜想“16位校验和”针对不是“信息送达”的可靠性相关。这是分析问题的一种优秀的方式你要学习答UDP的“不可靠”与“校验和”不矛盾反而巧合证明了它的设计哲学“UDP校验和”是为了防止损坏的数据被滥用而不是保证送达。为什么设计校验和因为链路层比如以太网已经有CRC循环冗余校验了UDP为什么还要自己再算一遍原因在于端到端的可靠性保障防止内存损坏数据从应用层拷贝到内核缓冲区再从内核缓冲区拷贝到网卡DMA直接内存访问区域这中间可能因为硬件比特翻转宇宙射线、电压不稳导致某一位0变1。防止中间设备篡改虽然路由器不修改数据但NAT网络地址转换设备可能重写IP头旧的路由器可能存在Bug导致数据拷贝时出错。防止“伪包”攻击校验和可以验证这个包是不是发给我的虽然不如TCP严格。UDP传输的特点1.无链接知道对端的IP和端口号就可以直接进行数据传输无需建立链接。2.不可靠没有确认机制没有重传机制。如果因为网络故障而没有到达UDP协议层也不会返回任何错误信息。3.面向数据报不能够灵活的控制读写数据的次数和数量。分包式传输面向数据报应用层交给 UDP 多长的报文UDP 原样发送既不会拆分也不会合并用 UDP 传输 100 个字节的数据:・如果发送端调用一次 sendto, 发送 100 个字节那么接收端也必须调用对应的一次 recvfrom, 接收 100 个字节而不能循环调用 10 次 recvfrom, 每次接收 10 个字节UDP的缓冲区UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核将由内核传输数据给网络层协议进行后续的传输动作。UDO具有接收缓冲区。但是这个缓冲区不能保证UDP报的顺序。满则丢弃UDP的socket既能读也能写。具有全双工的性质全双工Full-Duplex指的是通信双方可以同时进行发送和接收数据互不干扰。UDP 使用注意事项我们注意到UDP 协议首部中有一个 16 位的最大长度。也就是说一个 UDP 能传输的数据最大长度是64K(包含 UDP 首部).然而 64K 在当今的互联网环境下是一个非常小的数字.如果我们需要传输的数据超过 64K, 就需要在应用层手动的分包多次发送并在接收端手动拼装基于 UDP 的应用层协议・NFS: 网络文件系统・TFTP: 简单文件传输协议・DHCP: 动态主机配置协议・BOOTP: 启动协议 (用于无盘设备启动)・DNS: 域名解析协议当然也包括你自己写 UDP 程序时自定义的应用层协议感谢支持长期连载欢迎关注
传输层协议UDP原理讲解+多个有趣的发问
bit::Shadow✧(≖ ◡ ≖✿目录传输层端口号六元组端口号端口号范围划分端口号0-1023不是特定端口号吗为什么可以sudo绑定进程与端口号的关系UDP协议内核格式UDP数据加工UDP传输不是“不可靠”吗为什么还有16位校验和呢为什么设计校验和UDP传输的特点面向数据报UDP的缓冲区UDP 使用注意事项基于 UDP 的应用层协议传输层负责数据能够从发送端传输到接收端。端口号每个端口号都代表特定主机下的一个程序。IP代表一个主机六元组当数据从发送端的应用层-传输层-网络层-数据链路层之后得到端口号端口号范围划分【0,1023】固定/知名端口号HTTP, FTP, SSH等的固定的。 像SSH22 HTTP80【1024,65535】操作系统动态分配客户端程序。65536 2^16端口号0-1023不是特定端口号吗为什么可以sudo绑定要回答“为什么是固定的但sudo又能绑定”核心在于区分两个概念端口的使用规则协议规定和端口的绑定权限操作系统规定。简单来说0-1023的固定是“行业规范”而sudo能绑定是“操作系统许可”。规范约束的是软件开发者而许可约束的是系统用户。进程与端口号的关系怎样理解“一个进程可以绑定多个端口号而应该端口号只能绑定一个进程”1.因为一个进程里可以开很多个Socket套接字。进程是“容器”Socket是它的“子工具”。一个Web服务器比如Nginx启动后它可以同时bind(80)用于HTTP同时bind(443)用于HTTPS甚至再bind(8080)做个管理后台。这些端口号在操作系统内核的端口管理表里虽然端口号不同但它们对应的进程IDPID是同一个。2.端口号的设置是程序级设计目的在于标识系统下的唯一性程序。因此“只能绑定一个进程”否则如果有两个进程同时绑定80端口内核就混乱了“这个包到底该给谁”接下来在理解原理部分强调以下注意事项1. 构建立体化视角对于应用层、传输层、网络层。2.基于“应用层”的根基思考网络的层状结构。UDP协议内核格式路径linux-2.6.18\include\linux\udp.hUDP数据加工上部分就是位于传输层的UDP添加的报头。下端是有效载荷16位UDP长度表示自UDP首部UDP数据的最大长度。校验和如果校验和出错数据直接丢弃。UDP传输不是“不可靠”吗为什么还有16位校验和呢分析UDP“不可靠”绝对没错“不可靠”描述的是传输的“送达与否”。因此我们猜想“16位校验和”针对不是“信息送达”的可靠性相关。这是分析问题的一种优秀的方式你要学习答UDP的“不可靠”与“校验和”不矛盾反而巧合证明了它的设计哲学“UDP校验和”是为了防止损坏的数据被滥用而不是保证送达。为什么设计校验和因为链路层比如以太网已经有CRC循环冗余校验了UDP为什么还要自己再算一遍原因在于端到端的可靠性保障防止内存损坏数据从应用层拷贝到内核缓冲区再从内核缓冲区拷贝到网卡DMA直接内存访问区域这中间可能因为硬件比特翻转宇宙射线、电压不稳导致某一位0变1。防止中间设备篡改虽然路由器不修改数据但NAT网络地址转换设备可能重写IP头旧的路由器可能存在Bug导致数据拷贝时出错。防止“伪包”攻击校验和可以验证这个包是不是发给我的虽然不如TCP严格。UDP传输的特点1.无链接知道对端的IP和端口号就可以直接进行数据传输无需建立链接。2.不可靠没有确认机制没有重传机制。如果因为网络故障而没有到达UDP协议层也不会返回任何错误信息。3.面向数据报不能够灵活的控制读写数据的次数和数量。分包式传输面向数据报应用层交给 UDP 多长的报文UDP 原样发送既不会拆分也不会合并用 UDP 传输 100 个字节的数据:・如果发送端调用一次 sendto, 发送 100 个字节那么接收端也必须调用对应的一次 recvfrom, 接收 100 个字节而不能循环调用 10 次 recvfrom, 每次接收 10 个字节UDP的缓冲区UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核将由内核传输数据给网络层协议进行后续的传输动作。UDO具有接收缓冲区。但是这个缓冲区不能保证UDP报的顺序。满则丢弃UDP的socket既能读也能写。具有全双工的性质全双工Full-Duplex指的是通信双方可以同时进行发送和接收数据互不干扰。UDP 使用注意事项我们注意到UDP 协议首部中有一个 16 位的最大长度。也就是说一个 UDP 能传输的数据最大长度是64K(包含 UDP 首部).然而 64K 在当今的互联网环境下是一个非常小的数字.如果我们需要传输的数据超过 64K, 就需要在应用层手动的分包多次发送并在接收端手动拼装基于 UDP 的应用层协议・NFS: 网络文件系统・TFTP: 简单文件传输协议・DHCP: 动态主机配置协议・BOOTP: 启动协议 (用于无盘设备启动)・DNS: 域名解析协议当然也包括你自己写 UDP 程序时自定义的应用层协议感谢支持长期连载欢迎关注
