网站域名打不开的原因,网站必须做301重定向吗,广东南电建设集团网站,做网站网站再谈端口号端口号范围划分netstatpidof UDPUDP的特点面向数据报UDP的缓冲区 基于UDP的应用层协议 TCP认识TCP协议的报头理解封装解包理解可靠性TCP工作模式16位窗口大小6位标志位URGACKPSHRSTSYNFIN 再谈端口号
端口号(Port)标识了一个主机上进行通信的不同的应用程序 在TCP/I… 再谈端口号端口号范围划分netstatpidof UDPUDP的特点面向数据报UDP的缓冲区 基于UDP的应用层协议 TCP认识TCP协议的报头理解封装解包理解可靠性TCP工作模式16位窗口大小6位标志位URGACKPSHRSTSYNFIN 再谈端口号
端口号(Port)标识了一个主机上进行通信的不同的应用程序 在TCP/IP协议中用 “源IP” “源端口号” “目的IP” “目的端口号” “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看)
端口号范围划分
0 - 1023知名端口号HTTPFTPSSH等这些广为使用的应用层协议他们的端口号都是固定的1024 - 65535操作系统动态分配的端口号。客户端程序的端口号就是由操作系统从这个范围分配的
有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号
ssh服务器使用22端口ftp服务器使用21端口telnet服务器使用23端口http服务器使用80端口https服务器使用443端口
执行下面的命令, 可以看到知名端口号
cat /etc/services我们自己写一个程序使用端口号时, 要避开这些知名端口号
一个进程是否可以bind多个端口号? 一个端口号是否可以被多个进程bind? 进程与端口号的关系就是父与子的关系父亲可以有多个儿子而每个儿子只有一个父亲。进程可以bind多个端口号一个端口号只能被一个进程bind。
netstat
netstat是一个用来查看网络状态的重要工具 语法
netstat [选项]功能查看网络状态 常用选项
n 拒绝显示别名能显示数字的全部转化成数字l 仅列出有在 Listen (监听) 的服務状态p 显示建立相关链接的程序名t (tcp)仅显示tcp相关选项u (udp)仅显示udp相关选项a (all)显示所有选项默认不显示LISTEN相关
pidof
在查看服务器的进程id时非常方便 语法
pidof [进程名] 功能通过进程名, 查看进程id
UDP 16位UDP长度表示整个数据报(UDP首部UDP数据)的最大长度如果校验和出错就会直接丢弃
UDP的特点
UDP传输的过程类似于寄包裹你只能一个一个寄而不能寄1.5个。
无连接知道对端的IP和端口号就直接进行传输不需要建立连接不可靠没有确认机制没有重传机制如果因为网络故障该段无法发到对方UDP协议层也不会给应用层返回任何错误信息面向数据报不能够灵活的控制读写数据的次数和数量
面向数据报
应用层交给UDP多长的报文UDP原样发送既不会拆分也不会合并
用UDP传输100个字节的数据 如果发送端调用一次sendto发送100个字节那么接收端也必须调用对应的一次recvfrom接收100个字节而不能循环调用10次recvfrom每次接收10个字节
UDP的缓冲区
UDP没有真正意义上的 发送缓冲区调用sendto会直接交给内核由内核将数据传给网络层协议进行后续的传输动作UDP具有接收缓冲区但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致如果缓冲区满了再到达的UDP数据就会被丢弃
UDP的socket既能读也能写这个概念叫做 全双工
我们用的网络lO接口其实并不直接是发送和接受接口而是拷贝接口! 协议就是结构化数据 UDP使用注意事项
我们注意到UDP协议首部中有一个16位的最大长度也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。然而64K在当今的互联网环境下是一个非常小的数字。如果我们需要传输的数据超过64K就需要在应用层手动的分包多次发送并在接收端手动拼装
基于UDP的应用层协议
NFS: 网络文件系统TFTP: 简单文件传输协议DHCP: 动态主机配置协议BOOTP: 启动协议(用于无盘设备启动)DNS: 域名解析协议
当然也包括你自己写UDP程序时自定义的应用层协议;
TCP
TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;
认识TCP协议的报头 源/目的端口号表示数据是从哪个进程来到哪个进程去32位序号/32位确认号下面工作模式会有说明。4位TCP报头长度表示该TCP头部有多少个32位bit(有多少个4字节)所以TCP头部最大长度是15 * 4 606位标志位下面会详细说明 URG紧急指针是否有效 ACK确认号是否有效 PSH提示接收端应用程序立刻从TCP缓冲区把数据读走 RST对方要求重新建立连接我们把携带RST标识的称为复位报文段 SYN请求建立连接我们把携带SYN标识的称为同步报文段 FIN通知对方本端要关闭了我们称携带FIN标识的为结束报文段16位窗口大小下面会有16位校验和发送端填充CRC校验接收端校验不通过则认为数据有问题。此处的检验和不光包含TCP首部也包含TCP数据部分。16位紧急指针标识哪部分数据是紧急数据40字节头部选项暂时忽略 tcp协议是有标准长度的:20先读取20字节 转换成为一个结构化的数据立马提取标准报头中的4位首部长度 就能得到后续报头的剩余大小x * 4 - 20 0; x * 4 - 20 n; tcp报头的总长度0000-1111[015] tcp报文的总长度 4位首部长度 * 4字节 tcp报头的总长度0000-1111[0,15][060][20,60] 如果我们报头就是20字节那么4位首部长度应该填写多少呢? x * 4字节 20 、x 5 0101 只要把tcp报头处理读取完毕剩下的就是有效载荷
理解封装解包
我们收到一个报文是如何找到曾经bind特定port的进程的网络协议栈和文件是什么关系 系统有很多的场景需要我们快速定位一个进程bind就是将端口号及映射关系插入哈希表中。 理解可靠性
为什么网络传输的时候会存在不可靠问题 因为距离变长了导致出现可靠性问题。
不可靠问题常见都有哪些不可靠的场景? 丢包乱序校验错误重复…
如果距离长了存不存在绝对的可靠性
比如小明小红相隔1千米小明问小红吃饭了吗这条消息小明并不能确定小红是否收到。小红回小明她吃了。这时候小明才能确定她收到了这条消息。
我们认为只有收到了应答历史消息我才能100%确认对方收到确认应答了才算可靠双方通信一定存在最新的数据没有应答!—最新消息一般无法保证可靠性!
不存在绝对的可靠性存在相对的可靠性一个报文只要收到了应答就能保证该报文的可靠性 – 建立在确认应答上
TCP工作模式 双方两个朝向的可靠性双方在进行通信的时候可能除正常的数据段通信时也会涵盖确认数据段 tcp双方的地位是对等的只需要搞定一个朝向的通信过程 数据到达对面的顺序一定是和发送的顺序一样的吗?不一定
注定了应答报文对应的报头中必定涵盖了确认序号确认应答和确认序号接收方已经收到了ACK序号之前的所有真的所有且连续的报文。
为什么我们要有两组序号 是因为我们tcp通信是全双工的收发分别对应序号与确认序号
16位窗口大小 因为我们所构建的所有TCP报文都是要给对方发送的对客户端与服务端一样适用。很明显如果我们知道了对方的缓冲区大小我们也不需要发送过去了。互相交换接受能力。
6位标志位
tcp报文也是有类型的服务器会收到各种各样的tcp报文接收方要根据不同的tcp报文要有不同的动作。tcp正常的数据段有的就是ack…
URG URG紧急标志位 URGUrgent标志位用于指示 TCP 数据包中是否包含紧急数据。它被设置为1时表示该数据包中的某些数据被标记为紧急数据。紧急数据指示了一种需要尽快处理的情况通常是一些优先级较高的数据。
当 URG 标志位被设置为1时还需要使用16位的紧急指针字段Urgent Pointer来指示紧急数据在数据流中的位置。紧急指针指示了紧急数据的字节偏移量从而使接收方能够识别和处理这些紧急数据。 这些紧急数据可以称为带外数据 在 TCP 中带外数据通过使用紧急指针Urgent Pointer和 URG紧急标志位来标识和处理。当发送端发送带外数据时它会设置 URG 标志位并指定紧急指针的位置以通知接收端有紧急数据需要处理。接收端在收到带有 URG 标志位的数据时会根据紧急指针指示的位置来处理这些带外数据。
带外数据的使用可以根据具体的应用协议和实现进行定义。一些常见的应用包括
Telnet 协议Telnet 协议中使用带外数据来发送终止命令或中断信号以立即中断当前的操作。FTP 协议FTP 协议中使用带外数据来传输一些控制信息例如中断传输或终止文件传输的命令。窗口大小调整在 TCP 连接中带外数据可以用于通知对方调整发送或接收窗口的大小以便更有效地利用网络带宽。
URG 标志位主要用于紧急数据的通信和处理。当 TCP 连接的一方发送紧急数据时它可以使用 URG 标志位来通知接收方以便接收方能够及时处理这些数据。在实际应用中紧急数据的处理方式和含义可以根据具体的应用协议和实现进行定义。
需要注意的是URG 标志位的具体使用和处理是由应用层协议和操作系统决定的。因此不同的应用程序和操作系统可能有不同的处理方式和行为。
ACK ACK确认标志位 ACKAcknowledgment标志位用于指示 TCP 数据包中的确认号Acknowledgment Number字段是否有效。它被设置为1时表示 TCP 数据包中的确认号字段包含有效的确认信息。
在 TCP 连接中数据的传输是通过发送方将数据分割为多个 TCP 数据包并发送接收方接收到这些数据包后会发送确认信息给发送方。确认信息中包含了接收方期望收到的下一个字节的序号即确认号。通过设置 ACK 标志位为1发送方可以知道接收方已经成功接收到了之前发送的数据。 TCP将每个字节的数据都进行了编号即为序列号每一个ACK都带有对应的确认序列号 意思是告诉发送者我已经收到了哪些数据下一次你从哪里开始发 我们把TCP里的发送缓冲区当做数组只要将数据从应用层拷贝到了发送缓冲区每个字节就天然有了序列号。
ACK 标志位在 TCP 的三次握手过程中也起到了重要的作用。在建立 TCP 连接时客户端和服务器之间会互相发送带有 SYN同步和 ACK 标志位的数据包用于确认连接的建立和同步序号的交换。
需要注意的是ACK 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在 TCP 连接中发送方和接收方会根据 ACK 标志位的设置来确认数据的传输情况并进行相应的处理。
PSH PSHPush标志位 PSHPush标志位用于指示 TCP 数据包中的数据应该被立即推送给应用层而不是等待缓冲区填满或等待计时器超时。当 PSH 标志位被设置为1时发送方通知接收方应该立即将接收到的数据提交给上层应用进行处理。
通常情况下TCP 数据报在发送方的缓冲区中进行累积直到缓冲区填满或者等待一定的时间才会发送出去。这种方式可以提高网络传输的效率因为可以将多个数据报一起发送。但在某些情况下需要立即将数据推送给接收方的应用层。
例如在实时通信或交互式应用中延迟会对用户体验产生不利影响。通过设置 PSH 标志位为1发送方可以指示接收方在接收到该数据报后立即将数据提交给应用层处理从而减少传输延迟。
需要注意的是PSH 标志位的具体使用和处理是由应用层协议和操作系统决定的。应用程序和操作系统可以根据自身需求来决定何时设置 PSH 标志位以满足特定的数据传输要求。
RST RST复位标志位 RSTReset标志位用于指示 TCP 数据包中的复位请求。当 RST 标志位被设置为1时它表示发送方或接收方希望立即中断当前的 TCP 连接并进行连接的复位操作。
RST 标志位通常用于表示发生了严重的错误或异常情况导致当前的连接无法继续进行。当一方发送带有 RST 标志位的 TCP 数据包时它相当于向对方发送了一个连接复位请求要求对方放弃当前的连接并重新建立新的连接。
RST 标志位的使用场景包括
非法连接或攻击当网络设备或应用程序检测到非法连接或攻击时可以发送带有 RST 标志位的数据包以中断与攻击者的连接并保护系统的安全。异常情况处理当发生一些严重的异常情况如网络故障、连接超时或协议错误等可以使用 RST 标志位来中断当前的连接并重新建立新的连接。拒绝服务防护在面对拒绝服务DoS攻击或过载情况下网络设备或服务可以使用 RST 标志位来拒绝新的连接请求并释放已建立的连接资源。
需要注意的是RST 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在收到带有 RST 标志位的数据包时接收方会根据协议规定的处理方式来中断连接并进行相应的处理。
SYN SYN同步标志位 SYNSynchronize标志位用于在建立 TCP 连接时进行同步和协商。在 TCP 的三次握手过程中SYN 标志位扮演了重要的角色。
当发送方希望建立一个新的 TCP 连接时它会发送一个带有 SYN 标志位的数据包给接收方。这个数据包中包含一个初始序列号Initial Sequence Number用于标识数据流的起始位置。通过设置 SYN 标志位为1发送方告诉接收方它希望建立一个新的连接并将初始序列号设置为指定的值。
接收方收到带有 SYN 标志位的数据包后会发送一个带有 SYN 和 ACK确认标志位的数据包作为回应。这个数据包中包含确认号Acknowledgment Number字段表明接收方期望收到的下一个字节的序号并且也包含一个自己选择的初始序列号。
最后发送方收到接收方的 SYNACK 数据包后会发送一个带有 ACK 标志位的数据包作为确认。这个数据包中的确认号字段表示发送方期望接收到的下一个字节的序号。
通过这个三次握手的过程发送方和接收方可以建立起双向的、可靠的 TCP 连接并同步序列号和确认号以确保数据的可靠传输。
需要注意的是SYN 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在 TCP 连接的建立过程中发送方和接收方会根据 SYN 标志位的设置和响应来完成连接的建立和同步操作。
FIN FIN结束标志位 FINFinish标志位用于表示发送方已经完成发送数据并且要求关闭连接。当一个 TCP 连接的一方发送带有 FIN 标志位的数据包时它表示它已经没有更多的数据要发送并且希望关闭连接。
FIN 标志位的使用场景包括
正常关闭连接当发送方发送完所有的数据后它会发送一个带有 FIN 标志位的数据包告知接收方已经没有更多数据需要发送并请求关闭连接。异常关闭连接在某些情况下连接的一方可能会遇到异常情况如应用程序崩溃、网络故障或连接超时等。在这种情况下该方会发送带有 FIN 标志位的数据包以请求关闭连接并指示对方不要再发送数据。
当一方收到带有 FIN 标志位的数据包时它会发送一个带有 ACK确认标志位的数据包作为确认表示已经收到关闭请求。然后它也可以选择发送带有 FIN 标志位的数据包表示它也已经完成发送数据并请求关闭连接。
通过这种方式双方可以逐步关闭连接确保双向的数据都已经发送完毕并最终关闭连接。
需要注意的是FIN 标志位的具体使用和处理是由 TCP 协议和操作系统决定的。在 TCP 连接关闭过程中发送方和接收方会根据 FIN 标志位的设置和响应来完成连接的逐步关闭。 如有错误或者不清楚的地方欢迎私信或者评论指出
