网站网格设计,免费软件下载网,望京网站建设公司,怎么查询网站的外链之前讲过的http与https都是应用层协议#xff0c;当应用层协议将报文构建好之后就要将报文往下层传输层进行传递#xff0c;而传输层就是负责将数据能够从发送端传到接收端。
再谈端口号
端口号(port)标识了一个主机上进行通信的不同的应用程序#xff0c;在TCP/IP协议中当应用层协议将报文构建好之后就要将报文往下层传输层进行传递而传输层就是负责将数据能够从发送端传到接收端。
再谈端口号
端口号(port)标识了一个主机上进行通信的不同的应用程序在TCP/IP协议中用源IP源端口号目的IP目的端口号协议号这样一个五元组来标识一个通信。
端口号范围划分
0 - 1023知名端口号HTTPFTPSSH等这些广为使用的应用层协议他们的端口号都是固定的1024 - 65535操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的 执行指令 cat /etc/services 就可以看到知名端口号
netstat
netstat是一个用来检查网络状态的重要工具 语法 netstat [选项] 功能查看网络状态 常用选项
n 拒绝显示别名能显示数字的全部转化成数字l 仅列出有在 Listen (监听) 的服務状态p 显示建立相关链接的程序名t (tcp)仅显示tcp相关选项u (udp)仅显示udp相关选项a (all)显示所有选项默认不显示LISTEN相关
pidof
在查看服务器的进程id时非常方便. 语法 pidof [进程名] 功能通过进程名, 查看进程id
UDP协议
UDP协议端格式 16位UDP长度表示整个数据报(UDP首部 UDP数据)的最大长度如果校验和出错就会直接丢弃有效载荷部分是从上层调用send或者write系统调用传入的。UDP协议的报头是固定长度的因此很容易就可以将报头与有效载荷分离通过16位的目的端口号就可以做到报文的有效交付
报文的本质、封装、解包
tcp/ip是属于操作系统的而Linux下操作系统是用C语言实现的那么udp协议也就是用C语言实现的。报头(协议)的本质就是结构化数据struct
struct udp_header // 结构体
{uint16_t src_port;uint16_t dst_port;uint16_t udp_len;uint16_t check;
}
struct udp_header // 位段
{uint32_t src_port: 16;uint32_t dst_port: 16;// ...
}
// 使用的时候就可以申请空间对空间进行强转
((struct udp_header*)p)-src_port // ...
((struct udp_header*)p)-dst_port // ...
((struct udp_header*)p)-udp_len // ...
((struct udp_header*)p)-check // ...UDP的特点
UDP传输的过程类似于寄信。
无连接知道对端的IP和端口号就直接进行传输不需要建立连接不可靠没有确认机制没有重传机制如果因为网络故障该段无法发到对方UDP协议层也不会给应用层返回任何错误信息面向数据报不能够灵活的控制读写数据的次数和数量
面向数据报
应用层交给UDP多长的报文UDP原样发送既不会拆分也不会合并 用UDP传输100个字节的数据
如果发送端调用一次sendto发送100个字节那么接收端也必须调用对应的一次recvfrom接收100个字节而不能循环调用10次recvfrom每次接收10个字节
UDP的缓冲区
UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核由内核将数据传给网络层协议进行后续的传输动作UDP具有接收缓冲区。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致如果缓冲区满了再到达的UDP数据就会被丢弃 UDP的socket既能读也能写这个概念叫做全双工。UDP的发送缓冲区与接收缓冲区不是同一个是线程安全的。
UDP使用注意事项
我们注意到UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。 然而64K在当今的互联网环境下是一个非常小的数字。如果我们需要传输的数据超过64K就需要在应用层手动的分包多次发送并在接收端手动拼装
基于UDP的应用层协议
NFS网络文件系统TFTP简单文件传输协议DHCP动态主机配置协议BOOTP启动协议用于无盘设备的启动DNS域名解析协议
TCP协议
TCP协议全称为传输控制协议 与UDP协议一样我们先来关注两个问题就是1.报头和有效载荷如何分离2.有效载荷如何做到交付 首先在TCP的协议中新增了一个选项字段若是没有这个字段就表示者报头的大小就是20字节若是在选项字段中存有数据那么其长度就可以从四位首部长度中进行获取。首部长度计算有基本单位4字节这个对应的就是报文每一行的长度那么4位首部长度表示的就是报文的报头一共有多少行这样进行计算的话就可以的值整个报头的范围就是0-60字节因此选项的有效长度就是40字节。举例一个例子没有选项字段的报头是20字节经过折算就表示在4位首部长度中需要填写的数值就是5 - 0101。
报头和有效载荷如何分离提取报文前20字节提取首部长度字段首部长度字段 * 4 - 20 报头完毕 有几个字节的选项剩下的就是有效载荷。通过柔性数组的方式就可以选择是否需要携带选项字段有效载荷如何做到交付目的端口号
TCP协议段格式 众所周知TCP的可靠的传输协议那么下面我们就从可靠性出发来理解TCP协议 要理解可靠性我们首先就要知道什么情况是不可靠的丢包少量大量、乱序、重复、校验失败、发送太慢/太快网络出问题会出现上述问题的关键就是因为通信双方的距离变长了。以丢包来说遇到这种情况有一个问题就是收发双方怎么知道这个报文丢了那么我们就需要正确的理解确认应答机制。
确认应答机制 如上图所示当C给S发送了数据时当C收到了来自于S的应答那么对于C来说S就100%收到了来自于C的数据如果在等待了一段时间之后C收不到来自于S的应答那么C就会直接的认为报文丢失。TCP的可靠性就是通过收到应答来进行保证的。对于TCP来说server端与Cilent端的地位是对等的都是通过这种确认应答的方式进行可靠性的保证的但是上述就还有一个问题就是虽然有着确认的机制但是最新的一次报文始终无法保证能被可靠的送达。我们能保证的只有局部的可靠性在收到确认应答的报文的时候意味着对应数据报文一定是被收到的。
TCP报头格式
序号与确认序号
在TCP报头中必定要包含序号例如发送序号为10的一个报文那么响应的报文的确认序号一定是11假设响应的报文的确认序号也为10下一次接收到的报文的序号是12应答的报文也是12这种情况下就无法判定11号报文是否收到因此响应的报文的确认序号一定是发送序号的下一位这样就可以表示X-1之前的报文已经全部收到了下一次的发送请从X编号开始。 那为什么序号与确认序号不能是一个字段必须是不同的字段对于一条响应报文来说他的首要功能就是对于报文的确认同时因为响应报文与接收到的报文格式都差不多的那么同样可以在这条响应报文中发送数据这样就可以将原本需要两条报文的信息压缩成一个应答请求报文32位序号表示S-C的数据序号32位的确认序号表示S-C的历史数据的确认。
16位窗口大小 - 流量控制 TCP协议进行工作时将需要传输的数据拷贝到TCP的发送缓冲区然后将数据发送到接受方的接收缓冲区当接受方的接收缓冲区已经打满的时候此时接收方就会直接将报文进行丢弃但是这样的处理显然是不合理的报文经过网络传输到接收端已经消耗了很多的网络资源不能够随意地丢弃。因此我们就需要对传输的数据的大小进行判断根据接收端的处理能力即接受缓冲区的大小来决定发送端的速度这个机制就叫做流量控制而16位窗口大小就是为了给对方发送自己的接受缓冲区的大小告诉对方自己的接受能力。
接收端将自己可以接收的缓冲区大小放入TCP首部中的 “窗口大小” 字段通过ACK端通知发送端窗口大小字段越大说明网络的吞吐量越高接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知给发送端发送端接受到这个窗口之后就会减慢自己的发送速度如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据但是需要定期发送一个窗口探测数据段使接收端把窗口大小告诉发送端同样接收端也会发送窗口更新的报文给发送端。 接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中有一个16位窗口字段就是存放了窗口大小信息那么问题来了16位数字最大表示65535那么TCP窗口最大就是65535字节么实际上TCP首部40字节选项中还包含了一个窗口扩大因子M实际窗口大小是窗口字段的值左移 M 位
16位校验和
校验和是为了对UDP/TCP的报头和有效载荷进行校验校验失败直接将报文丢弃。在TCP中就可以通过确认应答机制进行重传处理。
6位标志位
在同一个时刻有很多的客户端会向服务端发起各种各样的TCP请求比如有发起链接的、结束链接的、维持通信的等等正是因为报文是有不同的类型那么对于不同的报文需要有不同的处理动作而6位标志位就是为了用来表示不同类型的报文。
ACK: 该报文是一个确认应答报文可能会携带数据- 捎带应答PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段SYN: 该报文是一个连接请求报文 三次握手 1. SYN 2. SYNACK 3. ACKFIN: 该报文是一个连接断开的请求报文四次挥手URG: 紧急指针是否有效。16位紧急指针 - 一个偏移量紧急数据在有效载荷中的偏移量。紧急数据在有效载荷中只有一个字节。当有一些特殊的需求的时候就可以通过紧急指针的标志位的形式进行标识。带外数据在recv函数中的flag标志就有着这样的标志。
确认应答机制补
在TCP发送数据的时候需要将数据拷贝到发送缓冲区中那么我们将发送缓冲区看做是一个char类型的数组将每个字节的数据都进行了编号即为序列号。
超时重传机制
主机A发送数据给B之后可能因为网络拥堵等原因数据无法到达主机B如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发但是主机A未收到B发来的确认应答也有可能是因为ACK丢失了因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果。此时还有需要注意的就是在未接收到应答报文之前已经发送过的报文不能被发送缓冲区清理
超时时间确定
TCP为了保证无论在任何环境下都能比较高性能的通信因此会动态计算这个最大超时时间。
Linux中(BSD Unix和Windows也是如此)超时以500ms为一个单位进行控制每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后仍然得不到应答等待 2*500ms 后再进行重传。如果仍然得不到应答等待 4*500ms 进行重传。依次类推以指数形式递增。累计到一定的重传次数TCP认为网络或者对端主机出现异常强制关闭连接。
连接管理机制
正常情况下TCP要经过三次握手建立连接四次挥手断开连接 在进行TCP通信的时候在服务端和客户端会建立很多的连接在OS内部一定会同时存在多个建立好的连接并将这些建立好的连接进行管理 - 先描述再组织OS同样要建立管理连接的数据的数据结构。创建维护连接是有成本的这些操作都需要消耗内存与CPU。
三次握手
三次握手由客户端首先发起TCP的SYN报文然后服务端会响应SYNACK的报文当客户端收到服务端发送的报文之后就会在操作系统中建立连接最后客户端会向服务端再次发送一个响应ACK报文当服务端收到之后便会在自己的OS中建立并管理相应的连接。三次握手的过程由双方的OS中的TCP层自主完成。connect触发连接等待完成accept等待建立完成获取连接。在上述的建立连接的过程中我们只能保证前两次报文是一定被对方收到的至于最后一次的ACK报文是无法保证对方一定收到如果服务端收到就会完成连接若是未收到此时客户端以为连接已经建立开始发送数据报文但服务端未建立那么就会发送RST报文重新建立连接。因此三次握手的本质就是在赌最后一次的ACK被对方收到。 如果两次握手就意味着服务端在第一次收到客户端的SYN报文的时候就要建立连接连接很简单的就被建立一旦由人不断地发送SYN报文就会不断的建立连接这很容易就会受到攻击 – SYN洪水如果是奇数次握手由于一定是客户端先发起连接那么最后一次的应答报文一定是客户端发起的此时出现连接建立异常时的成本就会从服务端嫁接到客户端服务端只需要发起重新建立连接的请求即可。如果是四次握手或者是偶数次握手就有可能出现服务端先建立连接客户端后建立连接的情况这样一旦建立连接出现异常服务端的资源一定会收到影响这是不可取的。
三次握手没有明显设计漏洞一旦建立连接出现异常成本嫁接到clientserver端成本较低。验证双方通信信道的畅通情况 – 三次握手是验证全双工通信信道通常的最小成本。第一二次连接确保了客户端到服务端的全双工畅通第一三次连接确保了服务端的全双工畅通。
四次挥手
断开连接的四次挥手起始和建立连接的三次挥手是相似的建立连接的三次挥手中的第二次了可以进行拆分拆分为SYN与ACK两条报文只不过在建立连接的时候进行了合并。断开连接是双向的不仅客户端需要断开服务端同样需要断开。若是客户端主动断开连接客户端会进入FIN_WAIT_1状态并发送FIN报文然后服务端就会发出响应ACK报文并将状态转变为CLOSE_WAIT当客户端接收到ACK报文时将自己的状态转变为FIN_WAIT_2。然后服务端向客户端发起断开连接的报文并将自己的状态转变为LAST_ACK客户端收到FIN报文的时候发送ACK应答报文并将自己的状态置为TIME_WAIT等待一段时间后将连接关闭。
CLOSE_WAIT
从下图中就可以看出连接建立成功将客户端先退出再退出服务端的时候客户端就会出现第二张图中的TIME_WAIT状态。 在上述的第一张图片中我们可以看到里面有CLOSE_WAIT和FIN_WAIT2状态这是因为我们在编写代码的时候在通信结束的时候没有关闭fd这样服务端就会一直保持在CLOSE_WAIT状态而客户端的状态在保持一定时间之后就会自动退出。因此编写代码的时候一旦忘记关闭fd那么未使用的文件描述符就会越来越少乃至于最后程序崩溃。
TIME_WAIT
现在做一个测试首先启动server然后启动client然后用Ctrl-C使server终止这时马上再运行server结果是 可以看到对应的TCP连接状态是如下图所示的 同样我们如果在服务端与客户端连接已经建立完成的前提下关闭客户端也会出现客户端的TIME_WAIT现象但是由于客户端是由OS自动分配端口号的因此不会出现上述的问题。出现上述问题的原因就是当服务端关闭应用程序的时候此时底层的TCP连接并没有断开相对应的端口号还在被占用因此短时间内是无法使用重新该端口号的。
TCP协议规定主动关闭连接的一方要处于TIME_WAIT状态等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态。我们使用Ctrl-C终止了server所以server是主动关闭连接的一方在TIME_WAIT期间仍然不能再次监听同样的server端口MSL在RFC1122中规定为两分钟但是各操作系统的实现不同在Centos7上默认配置的值是60s可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值
为什么TIME_WAIT的时间是2MSL
MSL是TCP报文的最大生存时间因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启可能会收到来自上一个进程的迟到的数据但是这种数据很可能是错误的)同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失那么服务器会再重发一个FIN。这时虽然客户端的进程不在了但是TCP连接还在仍然可以重发LAST_ACK)。
解决TIME_WAIT状态引起的bind失败的方法
使用setsockopt()设置socket描述符的选项SO_REUSEADDR为1表示允许创建端口号相同但IP地址不同的多个socket描述符int opt 1; setsockopt(listenfd, SOLSOCKET, SO_REUSEADDR, opt, sizeof(opt));
滑动窗口
从上述的内容中我们可以学习到对于每一个发送的数据段都要给一个ACK确认应答收到确认应答之后再发送下一个数据段这样做有一个比较大的缺点收发的效率比较低下。既然一收一发的效率比较低下我们就可以一次发送多条的数据可以大大的提高性能。接收方是有接受能力上限的发送方发送数据一定要在对方能接受的前提下进行并发的发送根据目前我们将讲过的知识发送数据的量由对方的窗口大小决定。 滑动窗口其实就是发送缓冲区的一部分滑动窗口的大小和对方的接受能力有关滑动窗口本质上就是一段用数组下标表示的缓冲区区间。
滑动窗口只能向右滑动滑动窗口是浮动的取决于对方的接受能力即通告的窗口大小能变大end进行操作也能变小end不动start进行操作变为0之后就表示对方不能再接收数据了。应答也要按需到达那么应答的seqstart seq应答的winend start win滑动窗口内的报文如果第一个报文丢失了如果是ACK丢失那么没有关系应答报文中的确认序号表示的是X之前的报文全部收到了一样可以确定第一个报文已经被收到如果是数据丢失即使收到了后面的报文同样需要响应第一个报文的确认序号因为第一个报文未被收到发送方对报文进行补发。数据要支持重传就需要被暂时保存起来保存在滑动窗口中
快重传
当某一段报文段丢失之后发送端会一直收到 1001 这样的ACK就像是在提醒发送端 我想要的是 1001一样如果发送端主机连续三次收到了同样一个 “1001” 这样的应答就会将对应的数据 1001 - 2000 重新发送这个时候接收端收到了 1001 之后再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了被放到了接收端操作系统内核的接收缓冲区中这种机制被称为 “高速重发控制”(也叫 “快重传”)。超时重传与快重传一个决定了重传的下限一个决定了重传的上限。
拥塞控制
前面的叙述已经对收发双方的通信进行了部分讨论但是TCP的通信不仅仅只有收发双方还有网络不同的网络状态同样会影响数据的传输。当出现少量丢包的时候可以通过重传机制进行数据的重新发送当出现大量丢包的情况时就说明网络出现问题需要进行等待但是光光的等待也是不行的最佳的方案是减少发送量。当出现网络拥塞的时候1.要保证网络拥塞不能加重2. 在网络拥塞有起色的情况下尽快恢复网络通信。 TCP引入慢启动机制先发少量的数据探探路摸清当前的网络拥堵状态再决定按照多大的速度传输数据。 此处引入一个概念程为拥塞窗口发生了网络拥塞发送方要基本得知网络拥塞的严重情况必须要进行网络状态的检测-对当前状态的网络情况进行衡量 – 拥塞窗口网络的状态是变化的衡量网络健康状态即拥塞窗口的大小一定是变化的作为主机我们为了知道网络的健康状况就需要不断的进行尝试与探测。想办法得到当前网络的拥塞窗口。因此前文中所述的滑动窗口的大小应该为对端主机接受能力与网络的拥塞窗口的较小值。
发送开始的时候定义拥塞窗口大小为1每次收到一个ACK应答拥塞窗口加1每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小做比较取较小的值作为实际发送的窗口;为了不增长的那么快因此不能使拥塞窗口单纯的加倍此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候不再按照指数方式增长而是按照线性方式增长 当TCP开始启动的时候慢启动阈值等于窗口最大值在每次超时重发的时候慢启动阈值会变成原来的一半 同时拥塞窗口置回1
延迟应答
如果接收数据的主机立刻返回ACK应答这时候返回的窗口可能比较小。
假设接收端缓冲区为1M。一次收到了500K的数据如果立刻应答返回的窗口就是500K但实际上可能处理端处理的速度很快10ms之内就把500K数据从缓冲区消费掉了在这种情况下接收端处理还远没有达到自己的极限即使窗口再放大一些也能处理过来如果接收端稍微等一会再应答比如等待200ms再应答那么这个时候返回的窗口大小就是1M 一定要记得窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率 那么所有的包都可以延迟应答么? 肯定也不是数量限制每隔N个包就应答一次时间限制超过最大延迟时间就应答一次 具体的数量和超时时间依操作系统不同也有差异一般N取2超时时间取200ms
面向字节流
创建一个TCP的socket同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区
调用write时数据会先写入发送缓冲区中如果发送的字节数太长会被拆分成多个TCP的数据包发出如果发送的字节数太短就会先在缓冲区里等待等到缓冲区长度差不多了或者其他合适的时机发送出去接收数据的时候数据也是从网卡驱动程序到达内核的接收缓冲区然后应用程序可以调用read从接收缓冲区拿数据另一方面TCP的一个连接既有发送缓冲区也有接收缓冲区那么对于这一个连接既可以读数据也可以写数据。这个概念叫做 全双工 由于缓冲区的存在TCP程序的读和写不需要一一匹配例如写100个字节数据时可以调用一次write写100个字节也可以调用100次write每次写一个字节读100个字节数据时也完全不需要考虑写的时候是怎么写的既可以一次read 100个字节也可以一次read一个字节重复100次
粘包问题
粘包问题中的包指的是应用层的数据包。在TCP的协议头中没有如同UDP一样的 “报文长度” 这样的字段但是有一个序号这样的字段。站在传输层的角度TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。站在应用层的角度看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。 避免粘包问题就是要明确两个包之间的边界。 对于UDP如果还没有上层交付数据UDP的报文长度仍然在。同时UDP是一个一个把数据交付给应用层。就有很明确的数据边界。站在应用层的角度使用UDP的时候要么收到完整的UDP报文要么不收。不会出现半个的情况
TCP异常情况
进程终止进程终止会释放文件描述符仍然可以发送FIN和正常关闭没有什么区别。 机器重启和进程终止的情况相同。 机器掉电/网线断开接收端认为连接还在一旦接收端有写入操作接收端发现连接已经不在了就会进行reset。即使没有写入操作TCP自己也内置了一个保活定时器会定期询问对方是否还在。如果对方不在也会把连接释放。 另外, 应用层的某些协议, 也有一些这样的检测机制。例如HTTP长连接中也会定期检测对方的状态。例如QQ在QQ断线之后也会定期尝试重新连接。
TCP小结
为什么TCP这么复杂? 因为要保证可靠性同时又尽可能的提高性能。
可靠性 校验和序列号(按序到达)确认应答超时重发连接管理流量控制拥塞控制 提高性能 滑动窗口快速重传延迟应答捎带应答 其他 定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)
TCP相关实验
通过wireshark截取到的TCP流程
