如何网站做镜像,网站导航包括,太原网站优化工具方法,建设工程招投标网站一、应用层
1#xff09;发送接收流程
1. 发送文件
write 函数发送数据到 TCP 套接字时#xff0c;内容不一定会立即通过网络发送出去。这是因为网络通信涉及多个层次的缓冲和处理#xff0c;TCP 是一个面向连接的协议#xff0c;它需要进行一定的排队、确认和重传等处理…一、应用层
1发送接收流程
1. 发送文件
write 函数发送数据到 TCP 套接字时内容不一定会立即通过网络发送出去。这是因为网络通信涉及多个层次的缓冲和处理TCP 是一个面向连接的协议它需要进行一定的排队、确认和重传等处理。具体来说write 到 TCP 套接字并不意味着数据立刻发送到远程主机它可能会经历以下几个步骤 用户空间缓冲区当调用 write() 或 send() 发送数据时数据首先会被放入用户空间的缓冲区即应用程序的发送缓冲区。这时数据并没有立即从 TCP 套接字发送到网络只是暂时存放在内核中的缓冲区里等待进一步的处理。 TCP 内核缓冲区接着内核会将这些数据从用户空间缓冲区复制到 TCP 内核缓冲区。此时数据依然没有发送到网络只是存储在内核的发送缓冲区准备通过 TCP 连接发送。 等待确认TCP 协议本身是可靠的意味着它需要确保数据的可靠发送。TCP 会对每一部分数据进行分段packetization并按顺序发送。发送的数据会首先加入 TCP 内核缓冲区然后等待网络层处理、分段、传输。 网络传输经过以上处理后数据会通过网络层发送到目标主机。但这并不意味着数据在发送后就立即到达目标主机。由于 TCP 是面向连接的协议它还会确保数据正确传输可能涉及数据的重传、确认ACK等机制。 操作系统缓冲区与阻塞如果 TCP 套接字的发送缓冲区已满或者网络暂时无法处理数据write 调用可能会被阻塞直到缓冲区有空间或者网络恢复。如果是非阻塞模式下write 会立即返回表示数据已经进入内核缓冲区但并不一定已经完全通过网络发送。 完成通知虽然 write 函数调用可能很快返回但它返回的并不代表数据已经完全通过网络发送完成。实际上发送的数据可能会在内核缓冲区中保持一段时间等待网络状况、流量控制、拥塞控制等因素。
2. 读取文件
read 函数读取 TCP 套接字时内容并不一定是立即从网络接收到的。TCP 协议涉及多个缓冲和处理步骤数据在内核缓冲区中可能排队直到满足某些条件后才会传递给应用程序。以下是 read 函数处理过程的步骤
内核接收缓冲区当远程主机通过网络发送数据到本地计算机时这些数据首先会通过网络层传输并到达操作系统的 接收缓冲区。这时数据并没有直接交给应用层而是暂时存储在内核的缓冲区中等待进一步的处理。数据排队与处理接收到的数据可能会排队在缓冲区内。虽然 read 或 recv 函数已经被调用但这些数据可能并未立即交给应用程序。操作系统内核会根据缓冲区的状态、网络环境以及流量控制等因素决定什么时候把数据交给应用层。等待数据可用如果接收缓冲区中已有数据read 会立即返回相应的数据。如果缓冲区为空read 会进入阻塞状态直到数据到达并准备好读取。这时操作系统会等待远程主机的进一步数据传输或本地网络环境的变化。流量控制与延迟TCP 协议有流量控制和拥塞控制机制确保数据传输的可靠性与稳定性。但这些机制也可能导致读取数据的延迟即使数据已经通过网络到达可能因为缓冲区或流量控制的限制数据还未被传递给应用程序。读取过程中的分段与组合由于 TCP 是流协议传输的数据可能是分段的。即使应用程序调用 read 或 recv也有可能只接收到部分数据包或数据块。这是因为 TCP 会将大块数据分为多个小段传输应用层需要处理这些分段数据并将其拼接。阻塞与非阻塞模式 阻塞模式如果套接字处于阻塞模式read 会等待直到有数据可以读取。如果接收缓冲区中没有数据read 会阻塞直到接收到来自远程主机的数据并可供读取。非阻塞模式如果套接字处于非阻塞模式read 会立即返回。如果没有数据可以读取它会返回 -1 并设置 errno 为 EAGAIN 或 EWOULDBLOCK表示暂时没有数据可读。 数据交付与应用层读取 如果内核缓冲区中有数据read 会从缓冲区中将数据交付给应用层。此时应用层可以开始处理接收到的数据。如果接收缓冲区中没有数据read 将等待更多数据传输到缓冲区直到数据可用。 内核的 read 行为当应用程序调用 read 时操作系统内核会检查接收缓冲区中是否有数据。如果缓冲区中有数据内核会将其交给应用程序如果缓冲区为空read 会阻塞直到新的数据到达。整个过程受网络状况、流量控制、操作系统调度等多方面因素的影响。
2HTTP协议
1. 序列化与反序列化
HTTP协议中的序列化与反序列化主要指的是将请求和响应的内容从程序数据结构转化为字符串格式序列化以及将字符串格式的HTTP消息转换回程序数据结构反序列化的过程。 序列化是将数据结构转换成可以存储或传输的格式 反序列化是序列化的逆操作即将存储或传输的格式转化为相应的数据结构。 在HTTP请求和响应的交互中传输的消息通常是字符串格式因此序列化和反序列化非常重要。例如在客户端向服务器发送请求时HTTP请求会被序列化为一条字符串并通过网络发送在服务器接收到该请求时它会反序列化请求并进行处理最终返回HTTP响应并再次进行序列化。 2. URL
URLUniform Resource Locator统一资源定位符是用于定位网络资源的地址。URL通常由多个部分组成
协议Protocol如 http、https 等用于指定如何访问资源。主机名Host指定访问的服务器的域名或IP地址如 www.example.com。端口号Port在HTTP中通常是80HTTP和443HTTPS如果没有指定则默认使用这些端口。路径Path指向特定资源的路径如 /index.html。查询字符串Query可选的通常包含键值对用于指定参数如 ?namevalue。片段标识符Fragment可选的用于指定文档内的某个位置如 #section1。
3. HTTP请求 请求行Request Line请求行是HTTP请求的第一行。 请求方法 请求URI HTTP版本 GET /index.html HTTP/1.1请求方法指定要执行的操作如 GET、POST、PUT、DELETE 等。请求URI指定资源的路径通常是请求的地址或服务器上的资源路径。它可以包含查询参数Query String。HTTP版本指定HTTP协议的版本一般是HTTP/1.1或HTTP/2。 请求报头Request Headers紧随请求行之后的部分包含多个键值对每一行描述了客户端的元数据。请求头提供了额外的控制信息比如客户端能力、认证信息、请求的内容类型等。 头部字段名: 字段值 Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,image/apng,*/*;q0.8 Host指定服务器的域名和端口。User-Agent标识发起请求的客户端软件如浏览器。Accept指定客户端能够接受的内容类型如 text/html, application/json 等。Authorization包含认证信息如基本认证的用户名和密码。Content-Type指定请求正文的类型通常用于POST或PUT请求。Accept-Encoding指定客户端支持的内容编码如gzip。Connection指定连接的管理方式如keep-alive。 请求正文Request Body请求正文是请求中的可选部分用于发送数据给服务器尤其在POST、PUT、PATCH等请求方法中通常用于提交表单数据、上传文件等。请求正文的内容是数据的实际载体可以是HTML表单数据、JSON、XML等格式。 {username: john_doe,password: password123
}请求正文的内容和格式通常由Content-Type请求头来指定。常见的格式有 application/x-www-form-urlencoded用于提交表单数据通常是简单的键值对。multipart/form-data用于上传文件时使用的表单格式。application/json用于传输JSON数据。text/plain纯文本数据。 请求报文示例 GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html4. HTTP响应 状态行状态行是HTTP响应的第一行包含了以下三部分信息 HTTP版本 状态码 状态描述 HTTP/1.1 200 OKHTTP版本指示HTTP协议的版本如HTTP/1.1。状态码三位数字代码用来表示响应的结果。状态描述对状态码的简单说明。 响应报头Response Headers响应头部分包含多个字段提供了有关响应的额外信息如响应的类型、服务器信息、内容长度等。常见的响应头包括。 头部字段名: 字段值 Content-Type: text/html; charsetUTF-8
Content-Length: 1234
Server: Apache/2.4.41 (Ubuntu)
Date: Sat, 27 Nov 2021 12:00:00 GMTContent-Type表示响应主体的媒体类型如 text/html, application/json。Content-Length表示响应正文的长度。Server服务器的名称和版本。Date响应生成的日期和时间。Location用于重定向表示资源的新位置如在301或302状态码时。Set-Cookie服务器返回给客户端的Cookie信息。Cache-Control指定缓存策略如是否缓存、缓存时间等。Connection指定是否保持连接如keep-alive。 响应正文Response Body响应正文部分包含实际的数据内容是响应的主体。它通常是客户端请求的资源可能是HTML页面、图片、JSON数据、音频、视频等。响应正文的格式通常由Content-Type响应头指定常见的格式有 // HTML响应正文
htmlheadtitleExample/title/headbodyh1Welcome to the Example Page/h1/body
/htmltext/htmlHTML页面。application/jsonJSON数据。image/jpegJPEG格式的图片。audio/mpegMP3格式的音频。 响应报文示例 HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html
Content-Length: 1234html.../html4. HTTP方法
HTTP协议定义了几种常见的请求方法用于表示客户端对服务器的不同操作请求 GET请求资源不携带请求体通常用于查询数据。 GET 请求 GET /search?queryexample HTTP/1.1 HTML表单的 GET请求 form actionsearch methodGET !-- 定义表单使用 GET 方法 --input typetext namequery placeholderSearch !-- 搜索框用户输入搜索内容 --input typesubmit valueSearch !-- 提交按钮 --
/formGET 特点 数据放在 URL 中GET 请求会将数据附加在 URL 后面通常是以查询字符串的形式。例如https://www.example.com/login?usernameadminpassword1234 无副作用GET 请求一般用于获取资源不应对服务器上的数据进行修改或产生副作用。因此GET 请求应该是安全的和幂等的即多次相同的请求会产生相同的结果。 请求数据量有限因为数据附加在 URL 后面所以 URL 长度受到限制通常是 2048 个字符因此不适合传输大量数据。 缓存GET 请求可以被缓存如果服务器设置了缓存策略并且浏览器通常会缓存 GET 请求的响应结果。 浏览器历史记录由于数据在 URL 中因此它们会被记录在浏览器的历史记录中用户可以查看、修改 URL。 POST提交数据当用户提交表单时数据不会出现在 URL 中而是通过请求体发送。 POST请求 POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 25usernameadminpassword1234HTML表单的 POST请求 form actionlogin methodPOSTinput typetext nameusername placeholderUsernameinput typepassword namepassword placeholderPasswordinput typesubmit valueLogin
/formPOST特点 数据放在请求体中与 GET 不同POST 请求的数据不会出现在 URL 中而是放在请求的主体部分。因此POST 请求可以发送大量的数据不受 URL 长度限制。 有副作用POST 请求通常用于向服务器提交数据并创建或修改资源。例如提交表单数据、上传文件等。由于 POST 请求会导致数据修改它应该是非幂等的即每次请求都可能导致不同的结果。 不被缓存POST 请求通常不会被缓存因为它可能会引起数据的变化。 没有长度限制由于数据在请求体中所以 POST 请求可以传输大量数据适合上传文件或提交大量表单数据。 浏览器历史记录POST 请求不会将数据存储在浏览器的地址栏和历史记录中因此它比 GET 更适合处理敏感信息。 PUT更新资源通常用于更新数据。 DELETE删除资源。 HEAD类似于GET但服务器只返回响应头不返回响应体。 OPTIONS查询支持的方法或服务器的能力。 PATCH部分更新资源。 HTTP方法95%使用GET和POST 特性GETPOST数据位置URL 查询字符串请求体body数据长度限制受 URL 长度限制通常为 2048 字符没有限制安全性数据暴露在 URL 中安全性差数据不暴露在 URL 中安全性好用途获取数据查询信息提交数据修改或创建资源是否可以缓存可以缓存不可以缓存是否能通过书签保存可以因为数据在 URL 中不可以数据不在 URL 中
5. HTTP状态码
HTTP状态码用于表示服务器处理请求的结果它们分为五个类别 1xx信息性状态码表示请求已被接收正在处理。 2xx 成功状态码表示请求已成功处理并返回结果。 200 OK请求成功。201 Created资源已成功创建。204 No Content请求成功但没有返回数据。 3xx 重定向状态码表示需要客户端进一步操作以完成请求。 301 Moved Permanently资源已永久移动到新的位置。302 Found资源临时移到新的位置。 4xx 客户端错误状态码表示请求有语法错误或无法完成请求。 400 Bad Request请求格式错误。401 Unauthorized未授权缺少认证信息。404 Not Found请求的资源不存在。 5xx 服务器错误状态码表示服务器未能处理有效请求。 500 Internal Server Error服务器内部错误。503 Service Unavailable服务不可用通常是服务器过载或维护。
6. HTTP常见Header
HTTP请求和响应头用于传递额外的信息常见的有 Host指定服务器的主机名和端口号。 Host: www.example.com说明该头部字段在HTTP/1.1中变得强制因为它支持虚拟主机功能。在一个IP地址下可能托管多个网站Host 字段帮助服务器确定目标网站。 Connection控制连接的持续方式。 Connection: keep-alive保持连接
Connection: close关闭连接说明控制客户端和服务器在完成请求-响应周期后是关闭连接还是保持连接用于后续请求。keep-alive 常用于 HTTP/1.1 协议中表示连接可以复用。 User-Agent标识发出请求的客户端软件。 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36说明通常用于识别浏览器和操作系统信息。它告诉服务器请求是来自于什么平台和软件帮助服务器做适当的响应。 Location指示客户端应访问的新 URL通常用于重定向。 Location: https://www.newdomain.com说明如果服务器需要客户端访问另一个资源通常会返回该字段指示客户端应发起新的请求。 Content-Type指示响应体中的数据类型。 Content-Type: application/json
Content-Type: text/html说明该字段告诉客户端响应体的类型从而使客户端能够正确解析和显示内容。 Content-Length指示响应体的大小。 Content-Length: 1234Set-Cookie指示服务器发送给客户端的 cookie。 Set-Cookie: sessionId123456; expiresThu, 01 Jan 2023 00:00:00 GMT; path/说明该字段用来设置客户端的 cookie服务器通过设置 cookie 来在后续请求中识别客户端。 CookieCookie 是服务器发送到浏览器的一小段数据浏览器会将其存储并在每次后续请求时将其发送回服务器。Cookie 可以存储一些用户的偏好设置、认证信息、会话标识符等。Session IDSession 是服务器端的一个机制它用于存储关于用户会话的状态信息。Session ID 是一个唯一的标识符用来标识一个用户的会话。这个 Session ID 通常会存储在 Cookie 中或通过 URL 传递。为了提高安全性现在大多数 Web 应用会采用 Session ID 来记录用户的登录状态而不是直接将账户密码等敏感信息存储在 Cookie 中。Cookie 只是用来存储标识符如 Session ID而实际的用户数据则由服务器管理。
3HTTPS
HTTPSHyperText Transfer Protocol Secure是HTTP的安全版本它通过在HTTP的基础上增加SSL/TLS加密层来保证通信的安全性。
1. HTTPS与HTTP的区别
加密HTTPS在HTTP的基础上加入了SSL/TLS加密协议用于确保数据在传输过程中不会被窃取或篡改。HTTP是明文传输而HTTPS是加密传输。认证HTTPS使用数字证书来验证通信的双方确保你与正确的服务器进行通信而HTTP不做任何认证可能存在中间人攻击Man-in-the-Middle。数据完整性HTTPS保证数据在传输过程中不被篡改使用散列Hashing技术确保数据的完整性。HTTP在这方面没有任何机制。
2. CA认证
CACertificate Authority证书颁发机构是一个受信任的第三方机构负责发放、管理和验证数字证书。数字证书用于保证信息传输的安全性尤其是通过 HTTPS、SSL/TLS 协议进行的加密通信。CA认证的主要目的是确认网站或服务器的身份确保客户端可以信任该服务器。在互联网上当访问一个安全的网站例如https://www.example.com浏览器会向网站服务器验证其数字证书是否由一个被信任的CA颁发。这个过程就是“CA认证”的应用。
CA认证基于 公钥基础设施PKI体系结构PKI 是由密钥对、数字证书、认证机构等组成的一套框架主要包括以下几个步骤 申请证书申请公钥与私钥对在整个认证流程中首先需要生成一个公钥和私钥对。这个过程由 服务器 负责具体步骤如下 生成公钥和私钥对服务器使用加密算法如RSA、ECDSA等生成一对密钥其中公钥是用来加密信息或验证签名的私钥则用于解密信息或创建数字签名。 生成证书签名请求CSR服务器会将生成的公钥和其他信息如域名、申请者信息等打包成一个证书签名请求CSR。需要注意的是这个请求中不能包含私钥信息。 提交CSR服务器将CSR提交给CA机构进行验证和签发证书。CSR中包含了申请者的身份信息以及公钥。 CA审核信息 CA审核过程CA机构接收到服务器发来的CSR后会对申请者的身份进行验证通常会验证申请者提供的信息是否真实有效包括域名的所有权、申请者身份等。 证书签发准备在验证完成后CA会准备签发证书证书中将包括服务器的公钥、有效期、CA的签名等信息。 签发证书CA使用其私钥对证书进行签名。数字证书中包含了以下信息 服务器的公钥来自CSR CA的签名证明该证书是由可信的CA签发的 证书的有效期 证书持有者的身份信息 域名 证书序列号 证书返回CA将签发的证书返回给申请者服务器会将其部署在自己的网站上这时服务器可以使用这个证书来实现安全通信。客户端收到证书后会验证证书的有效性。 客户端验证证书客户端例如浏览器收到服务器的证书后会执行以下验证步骤 验证证书链客户端会验证证书是否由受信任的 CA 颁发通常通过证书链的方式进行验证。客户端会检查证书的签名确认它是否由已知的根证书根CA签发。 验证证书有效期客户端还会检查证书的有效期确保其在当前时间内有效。 验证域名匹配客户端会检查证书中的域名与当前访问的服务器的域名是否匹配。 验证其他信息客户端还会进行其他的验证如是否存在证书撤销等问题。 加密通信密钥交换在客户端成功验证证书后双方可以使用公钥和私钥进行加密通信 密钥交换通过加密的方式客户端和服务器将会建立一个安全的通信通道确保双方的数据传输是加密的。 加密通信所有后续的通信都将使用加密通道进行保护防止中间人攻击和数据篡改。
二、传输层
1UDP用户数据报协议
UDP 是一种无连接的传输层协议属于 Internet协议族。与 TCP传输控制协议相比UDP没有保证数据传输的可靠性也不进行流量控制和拥塞控制。它更适合用于那些对速度要求高但对数据丢失或者顺序不太敏感的应用。
1. UDP特点 无连接性UDP是一个无连接协议。在通信之前客户端和服务器不需要建立连接。每个数据包称为“数据报”都作为独立的单元进行发送并且发送之后不会等待确认。 不可靠性UDP不保证数据报的传输顺序也不确认数据是否成功到达。数据可能会丢失、重复或者顺序错乱。应用层需要自行处理这些问题如果有需要。 低延迟由于不进行复杂的错误检查和重传UDP协议的开销较小传输速度相对较快。它适用于对实时性要求较高的应用如视频流、在线游戏、VoIP等。 无流量控制和拥塞控制UDP没有内建的流量控制和拥塞控制机制这意味着UDP不会自动调整发送速率也不处理网络拥塞的情况。 适用于小数据包的传输UDP通常用于传输小数据包适合实时应用如DNS查询、实时语音和视频等。 面向数据报应用层交给UDP多长的报文、UDP原样发送既不会拆分也不会合并 用udp传输100个字节的数据。如果发送端调用一次Sendto发送100个字节那么接收端也必须调用对应的一次Recvfrom、接收100个字节而不能循环调用10次Recvfrom每次接收10个字节。
2. UDP报头的本质 UDP报头UDP的数据包格式非常简单只有4个字段总计8个字节。 字段名称长度说明源端口号16位发送方的端口号目标端口号16位接收方的端口号长度16位数据部分的总长度包括UDP头和数据校验和16位用于错误检查的字段确保数据在传输过程中未被篡改或损坏 struct_udp_header // UDP头部结构体
struct udp_header {uint16_t source_port; // 源端口号uint16_t dest_port; // 目标端口号uint16_t length; // UDP头部和数据的总长度uint16_t checksum; // 校验和
};3. 基于UDP的应用层协议
DNS域名系统DNS是互联网中最重要的协议之一它将人类易记的域名如 www.example.com解析为IP地址。DNS协议通常使用UDP进行通信尤其是进行查询时。DHCP动态主机配置协议DHCP用于为局域网中的计算机自动分配IP地址、子网掩码、网关等配置信息。DHCP使用UDP协议进行客户端与服务器之间的通信。RTP实时传输协议RTP用于音频和视频流的传输它广泛应用于VoIP语音通信和视频会议等实时应用中。RTP通常在UDP协议上实现因为它需要快速传输和低延迟。SNMP简单网络管理协议SNMP用于网络设备的监控和管理。网络设备如路由器、交换机使用SNMP协议向网络管理系统报告其状态、性能等信息。TFTP简单文件传输协议TFTP是一个非常简单的文件传输协议通常用于小型文件的传输例如操作系统引导、设备配置等。TFTP使用UDP作为其传输协议。
2TCP传输控制协议
TCP 是一种面向连接、可靠的传输层协议。它是 IP协议Internet Protocol中最重要的协议之一广泛用于互联网中的数据传输尤其是需要保证数据完整性和顺序的场景如网页浏览、文件传输、电子邮件等。
1. TCP的特点
面向连接TCP在数据传输之前需要先建立连接确保双方可以进行数据交换。这个过程叫做“三次握手”。可靠性TCP通过数据确认、重传机制、序列号等方式确保数据按顺序无误地到达接收方。有序性TCP保证数据的顺序接收方收到的数据会按照发送方发送的顺序进行排序。流量控制TCP使用流量控制来避免发送方发送数据过快导致接收方的缓冲区溢出。拥塞控制TCP通过拥塞控制算法来避免网络拥塞确保网络的稳定性。全双工通信TCP支持双向数据流的同时传输即可以在同一个连接中同时发送和接收数据。
2. TCP协议段
TCP协议段TCP Segment是TCP协议的数据单位。TCP协议段在网络中用于传输数据确保数据的可靠传输并提供流量控制和拥塞控制等功能。一个TCP协议段的结构包括多个字段用于控制数据的传输顺序、确认数据的接收、错误检测等。
TCP协议段格式通常包括以下主要部分
// 4 Bytes0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
--------------------------------
| Source Port(16bits) | Destination Port(16bits) | .......
-------------------------------- .......
| Sequence Number(32bits) | .......
-------------------------------- .......
| Acknowledgment Number(32bits) | .......
-------------------------------- 20Bysts
| Data | |C|E|U|A|P|R|S|F| | .......
| Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window(16bits) | .......
|(4bits)|(4bits)|R|E|G|K|H|T|N|N| | .......
-------------------------------- .......
| Checksum(16bits) | Urgent Pointer(16bits) | .......
--------------------------------
| [Options] |
--------------------------------
| |
. Data .
| |
--------------------------------源端口号Source Port 16位字段用于标识发送方应用程序的端口。 目标端口号Destination Port 16位字段用于标识接收方应用程序的端口。 序列号Sequence Number 用于标识数据流中的字节序号。对于每一个数据段TCP会分配一个唯一的序列号用于数据的排序和确认。初始序列号ISN是由双方在连接建立时通过三次握手来确定的。 确认号Acknowledgment Number: 如果ACK标志位为1表示接收方期望下一个接收到的数据字节的序号。该字段指示接收方期望从发送方接收的数据的下一个字节位置确保数据按序到达。 确认序号的意义确认序号之前的数据已经全部收到下一次发送从确认序号指定的序号开始发送。确认号与序列号不复用 可以同时发送和回复已经收到两个号会同时存在。 数据偏移Data Offset 4位字段表示TCP头部的长度以4字节为单位。它告知接收方TCP数据段头部的结束位置紧接着是数据部分。 保留位Reserved 4位为将来使用而保留的一组控制位。在生成段中必须为零。 标志位TCP标志位包含8个字段用于控制连接的建立、数据的确认、连接的关闭等。 CWR (Congestion Window Reduced)减少拥塞窗口标志。该标志位用于TCP流量控制表示发送方已经接收到拥塞通知并减少了其拥塞窗口。它通常用于拥塞控制机制中特别是在TCP的拥塞窗口减少过程中。 ECE (ECN Echo)显式拥塞通知回显标志。这个标志表示网络中发生了拥塞事件。如果ECNExplicit Congestion Notification被启用并且发送方收到了来自接收方的拥塞通知则该标志位会被设置。 CWR 和 ECE 标志位用于TCP协议的 显式拥塞通知ECN功能通常应用于支持 ECN 的网络中。 在许多 普通应用 中这些标志位不被使用因此它们在基础教程和常见实现中不被详细讨论。 它们的功能更多的是面向 高性能网络 和 网络调优而普通的应用开发、网络调试中不常需要关注这两个标志位。 URG (Urgent)紧急指针有效标志。如果该标志位为1则表示该数据包中紧急指针字段有效并且接收方应优先处理该数据。通常紧急数据会通过TCP的紧急指针机制进行标识。 在 Unix/Linux 系统中应用程序可以通过 send() 系统调用来发送带外数据并指定带外标志。接收端可以使用 recv() 或 recvfrom() 等接口来接收带外数据。 ACK (Acknowledgment)确认号有效标志。如果该标志位为1则表示确认号字段有效接收方确认接收到数据的正确性。ACK用于TCP连接的可靠数据传输过程中。 PSH (Push)推送功能标志。当该标志位为1时接收方应立即将收到的数据交给上层应用而不应将其缓存。这通常用于需要快速响应的实时数据传输。 RST (Reset)重置连接标志。当该标志位为1时表示需要重置连接。TCP会使用RST来表示非正常连接终止或拒绝一个新的连接请求。 SYN (Synchronize)同步标志。该标志用于连接的建立阶段。当一方想要建立连接时它会发送一个SYN包。SYN用于同步双方的序列号。 FIN (Finish)结束标志。该标志用于连接的关闭。当一方完成数据的发送并希望关闭连接时它会发送一个带有FIN标志的数据包。收到FIN标志的接收方会进行确认并结束连接。 窗口大小Window 16位字段用于流量控制表示接收方的缓冲区剩余容量即接收方最多可以接收的字节数。 校验和Checksum 16位字段主要用于检测TCP头部和数据部分的传输错误。校验和计算时包括TCP头部和数据部分的所有位以及伪头部源IP、目标IP等。 校验和的计算过程涉及16位的加法运算如果没有错误接收方计算出来的校验和应该为0。 紧急指针Urgent Pointer 16位字段如果URG标志为1则表示数据中有紧急数据紧急指针指示紧急数据的结束位置。 选项Options 可选字段用于扩展TCP协议的功能。例如最大报文段大小(MSS)、时间戳Timestamp等。
3. TCP的连接机制
TCP的核心任务是确保数据的可靠传输它通过以下几个关键机制实现这一目标 三次握手TCP连接的建立在建立TCP连接时客户端和服务器之间通过一个三次握手过程来确保双方都准备好通信。 ---------- ---------
| Client | | Server |
---------- ---------CLOSED | | CLOSED | | LISTENSYN_SENT |-----[SYN] seq100----------------| |----[SYNACK] seq300, ack101----| SYN_RCVD
ESTABLISHED|-----[ACK] ack301----------------|| | ESTABLISHED| | 第一次握手客户端发送一个带SYN标志的数据包SYN1告诉服务器“我想建立连接”。 第二次握手服务器收到客户端的SYN包后回复一个带SYN和ACK标志的数据包SYN1, ACK1表示同意连接并确认客户端的SYN。 第三次握手客户端收到服务器的确认后再次发送一个带ACK标志的数据包ACK1表示连接建立成功。 三次握手必要性 验证全双工同步双方的序列号三次握手的过程确保了双方的序列号被同步。这是因为TCP是一个 面向字节流 的协议在连接建立时双方必须知道彼此的初始序列号以便数据能够按顺序传输。防止旧连接的干扰如果没有三次握手的过程可能会发生 延迟的旧数据包 在网络中混淆新连接的情况。三次握手通过同步序列号和状态确保每个连接都是新的避免了之前的连接遗留数据影响当前连接。确保双方都准备好建立连接通过三次握手双方都可以确认对方处于能够进行数据传输的状态避免不必要的连接失败。防止资源浪费三次握手确保双方都确认对方的接收能力和发送能力避免因为没有资源准备好而浪费系统资源。即便连接失败了连接成本也是由客户端承担如果由服务端承担容易导致服务器出问题。 连接建立的成功和上层有没有accept没有关系 四次挥手TCP连接的断开在通信结束时双方需要通过四次挥手来断开连接。 ---------- ---------
| Client | | Server |
---------- ---------
ESTABLISHED| | ESTABLISHED| |
FIN_WAIT_1 |-----[FIN] seq500----------------| |----[ACK] ack501-----------------| CLOSE_WAIT
FIN_WAIT_2 |----[FIN] seq700, ack501--------| LAST_ACK TIME_WAIT |-----[ACK] ack701----------------| CLOSEDCLOSED | || |第一次挥手客户端发送一个带FIN标志的数据包FIN1请求断开连接。 第二次挥手服务器收到FIN包后确认断开并向客户端发送一个ACK包ACK1。 第三次挥手服务器准备好关闭连接发送一个带FIN标志的数据包FIN1给客户端。 第四次挥手客户端收到服务器的FIN包后确认断开并发送一个ACK包ACK1给服务器。至此连接断开。 四次挥手的必要性 保证双方数据传输完成四次挥手确保每一方都有机会完成它的数据传输确保没有数据丢失。如果不进行完整的关闭过程可能会出现数据没有完全传输的情况。 确保连接的有序关闭TCP是一个全双工协议即每个方向上都有独立的数据流。四次挥手使得连接能够分别关闭每一个方向的数据流确保双方的数据能够顺利传输完毕且不会干扰到对方的操作。 避免半开连接没有四次挥手可能会出现 半开连接即一方认为连接已关闭另一方仍在等待数据传输。四次挥手确保每一方都确认连接完全关闭避免了这种情况的发生。 TIME_WAIT状态主动关闭方进入 TIME_WAIT 状态确保最后一个ACK包能够到达对方防止由于网络延迟或数据丢失导致的连接关闭失败持续时间在30-60s不等。 数据传输 确认应答机制在 TCP 中数据的传输并不是盲目进行的。每当发送方传输一段数据接收方都需要确认其已成功接收。确认机制的核心思想是通过接收方发送的 确认包ACK 来通知发送方接收的数据已经被成功接收或者接收方期望接收的下一个数据是什么。 当接收方收到一个数据包时它会返回一个 ACKAcknowledgment包表示它已经成功接收到的数据。确认包中包含一个 确认号Acknowledgment Number指示接收方期望接收的下一个数据字节的序列号。如果接收方没有收到某些数据包它将继续等待并在重传超时后请求发送方重传丢失的数据。 超时重传机制当 TCP发送方 发送数据后如果在指定的时间内没有收到接收方的确认ACK包则认为该数据包丢失或未被正确接收发送方会重新发送该数据包直到接收到确认包为止。 RTO发送方等待确认包的最大时间。如果超出了这个时间发送方会认为数据包丢失触发重传。RTO 是根据网络的 往返时延RTT 和 RTT的变化量 来动态计算的具体的计算方式通常采用 加权移动平均 或 指数平滑 方法在Linux中通常是500ms。累计到一定的重传次数TCP认为网络或者对端主机出现异常强制关闭连接。 捎带应答它允许在数据包中不仅发送数据还能携带对接收数据的确认信息。简单来说发送方在发送数据的同时接收方也在相同的数据包中进行确认从而避免了单独发送确认包的开销。
4. TCP状态转换 服务端状态转换流程 CLOSED - LISTEN 触发条件服务器调用 listen() 函数。 行为启动监听指定端口等待客户端连接请求SYN报文。 关键点此时服务器准备好接受连接但尚未建立任何连接。 LISTEN - SYN_RCVD 触发条件收到客户端的SYN报文第一次握手。 行为将连接请求放入内核等待队列并向客户端发送 SYNACK 报文第二次握手。 关键点SYN_RCVD 是半连接状态服务端等待客户端确认ACK。 SYN_RCVD - ESTABLISHED 触发条件收到客户端的ACK报文第三次握手。 行为完成三次握手连接正式建立。 关键点此时服务端可以正常收发数据。 ESTABLISHED - CLOSE_WAIT 触发条件收到客户端的FIN报文第一次挥手。 行为发送ACK确认客户端的FIN第二次挥手并进入 CLOSE_WAIT 状态。 关键点服务端需处理完剩余数据后再关闭连接。 CLOSE_WAIT - LAST_ACK 触发条件服务端调用 close() 主动关闭连接。 行为向客户端发送FIN报文第三次挥手并进入 LAST_ACK 状态等待客户端最后的ACK。 关键点服务端需确保客户端收到FIN的确认。 LAST_ACK - CLOSED 触发条件收到客户端对FIN的ACK第四次挥手。 行为连接彻底关闭。 关键点服务端资源释放终止连接。 客户端状态转换流程 CLOSED - SYN_SENT 触发条件客户端调用 connect() 发起连接。 行为发送SYN报文第一次握手。 关键点客户端等待服务端的 SYNACK。 SYN_SENT - ESTABLISHED 触发条件收到服务端的 SYNACK第二次握手并发送ACK第三次握手。 行为连接建立完成。 关键点客户端开始正常通信。 ESTABLISHED - FIN_WAIT_1 触发条件客户端调用 close() 主动关闭连接。 行为发送FIN报文第一次挥手。 关键点客户端等待服务端的ACK。 FIN_WAIT_1 - FIN_WAIT_2 触发条件收到服务端对FIN的ACK第二次挥手。行为进入 FIN_WAIT_2 状态等待服务端的FIN。关键点此时客户端不再发送数据但可能接收数据。 FIN_WAIT_2 - TIME_WAIT 触发条件收到服务端的FIN报文第三次挥手。行为发送ACK确认服务端的FIN第四次挥手并进入 TIME_WAIT 状态等待2MSL报文最大生存时间。关键点2MSL确保网络中残留的旧报文失效避免影响新连接。 TIME_WAIT - CLOSED 触发条件2MSL超时。行为客户端彻底关闭连接。关键点资源释放连接终止。
5. TIME_WAIT状态
在 TCP协议 中连接关闭时主动关闭连接的一方需要进入 TIME_WAIT 状态。这一状态确保连接的可靠关闭避免因网络延迟等因素导致的 数据丢失 或 连接混淆。 TIME_WAIT状态的必要性 TIME_WAIT 状态的核心作用是确保所有的传输报文段包括丢失的报文段都已被接收并清除。具体来说TIME_WAIT 状态持续的时间是 2 * MSLMaximum Segment Lifetime最大报文生存时间。这一设计目的是保证在连接关闭后TCP协议能够有效地处理所有的延迟报文。 MSL 是指 TCP报文的最大生存时间即一个数据包在网络中可以存在的最长时间。按照 RFC 1122 的规定MSL一般为 2分钟但不同操作系统可能会有不同的默认值。例如在 CentOS 7 中默认的 MSL值 为 60秒可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 命令查看。 TIME_WAIT持续2 * MSL的原因 确保延迟数据包被清除在网络中可能会有一些 延迟的报文段即数据包的到达时间比预期的晚。这些报文段可能是由于网络中的路由延迟、交换机缓冲等原因造成的。将 TIME_WAIT 持续 2 * MSL 时间可以确保所有这些报文段被清除避免它们对后续连接造成干扰。 确保最后的ACK确认包可靠到达假设最后一个 ACK 包丢失了服务器会在 TIME_WAIT 状态中等待。如果丢失的 ACK 包没有到达服务器可以在 TIME_WAIT 状态下重发 FIN 包进行连接关闭确保数据能够可靠传输。即使客户端进程已经退出TCP连接仍然存在服务器仍然可以重发 LAST_ACK 包。 TIME_WAIT状态的挑战 端口号资源占用当一个服务器主动关闭连接时如客户端不再活跃服务器主动清理连接会产生大量的 TIME_WAIT 状态连接。每个连接都会占用一个 五元组源IP源端口目的IP目的端口协议在大规模连接场景下这可能导致端口号资源被大量占用进而影响到新的连接请求。 TCP连接数激增特别是在处理大量短时间内的连接请求时例如快速的HTTP请求、实时消息服务等每个连接关闭后都会进入 TIME_WAIT 状态。如果每秒有大量连接请求服务器会积累大量处于 TIME_WAIT 状态的连接导致无法快速重新绑定相同的端口。 解决TIME_WAIT状态引起的bind失败问题 在服务器的TCP连接没有完全断开之前不允许重新监听相同的端口。这对于一些高并发应用来说可能不太合理。特别是当服务器需要处理大量的客户端连接而每个连接的生存时间较短时服务器在每次主动关闭连接后会进入 TIME_WAIT 状态这时会导致 bind 失败或无法迅速重用端口。 为了解决这个问题可以通过设置 SO_REUSEADDR 套接字选项来允许端口的重复使用 SO_REUSEADDR允许套接字在 TIME_WAIT 状态时重用端口。通过将该选项设置为 1可以允许多个套接字绑定到相同的端口但它们必须有不同的IP地址。这样尽管端口处于 TIME_WAIT 状态新的连接仍然能够绑定到该端口。 如何设置SO_REUSEADDR 在服务器端使用 setsockopt() 系统调用来设置该选项。 int sockfd socket(AF_INET, SOCK_STREAM, 0);
int optval 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, optval, sizeof(optval));这行代码会允许 SO_REUSEADDR 套接字选项允许重用端口。通过这种方式即使在 TIME_WAIT 状态下也可以快速重用端口号。
3TCP机制详解
1. 流量控制机制
TCP使用 滑动窗口Sliding Window机制来实现流量控制。滑动窗口的大小由接收端通过 窗口大小字段 来告知发送端发送端通过窗口大小来调节自己的发送速率。 窗口大小字段Window Size 窗口大小 字段存在于 TCP报文头部 中表示接收端接收缓冲区的剩余可用空间大小即接收端能够接收的最大数据量。 窗口大小 的值由接收端在 ACK包 中进行反馈告诉发送端自己还有多少空间可以接收数据。发送端根据接收端的反馈来调整发送数据的速率。 窗口的动态调整 接收端缓冲区空间充足时接收端会将较大的 窗口大小 值放入 窗口大小字段告诉发送端可以继续高效地发送数据。 接收端缓冲区接近满时接收端会将 窗口大小字段 设置为较小的值告知发送端减缓发送速度。 接收端缓冲区满时接收端会将 窗口大小字段 设置为 0表示它已经没有缓冲区空间来接收更多数据。 零窗口Zero Window 当接收端的缓冲区满了且无法接收更多数据时它会将 窗口大小 设置为 0并通过 ACK 包告诉发送端停止发送数据。 发送端在接收到窗口为0的反馈后会暂停数据发送避免数据丢失。 窗口探测Window Probe 即使接收端的窗口大小为0发送端依然需要定期发送 窗口探测包以检查接收端缓冲区是否有空闲空间。 窗口探测包是一种非常小的包主要用于让接收端告知发送端当前的窗口大小。接收端一旦有足够的空间便会通过 窗口大小字段 告诉发送端允许继续发送数据。
2. 滑动窗口机制
TCP滑动窗口机制是一个核心特性它使得 TCP协议 在保证可靠性传输的同时能够提高传输效率。通过使用滑动窗口发送方可以在没有等待确认的情况下连续发送一定数量的数据取决于接收方窗口大小。如果某些数据包丢失TCP 协议会通过合适的重传机制确保数据正确到达。 发送数据发送方根据窗口大小连续发送数据如前四个段。这些数据被存储在 发送缓冲区 中直到接收到对应的确认应答ACK。 接收确认当接收方收到数据后它会返回 ACK包确认已接收到的数据。接收到的 ACK包 会告知发送方哪些数据已经被接收并通过 确认号 更新窗口。 滑动窗口一旦接收到确认发送方就可以将窗口向后滑动继续发送未发送的数据。这个过程依赖于接收方的反馈和窗口大小的调整。 一个窗口内的数据为什么不一次性发送 即使接收方的缓冲区可以接收大量数据网络本身的带宽和延迟也可能成为瓶颈。如果发送方一次性发送过多数据可能会导致网络中某些路由器或交换机过载造成 网络拥塞 或数据包丢失。 分段发送 数据有助于控制每次传输的数据量避免网络资源消耗过大并确保在遇到丢包时能够更有效地进行重传。 滑动窗口不会向左移动。 滑动窗口大小是可以变换的。 流量控制就是通过控制滑动窗口大小实现的。 3. 快重传机制
快重传机制 是 TCP 为解决 丢包 问题而引入的优化方案。它能够在接收到 重复ACK 后立即重发丢失的数据包而不需要等待超时重传。 重复ACK当接收方收到丢失的数据段时它会发送重复的 ACK包并告知发送方它期望收到的数据序列号。 三次重复ACK触发快重传如果发送方连续收到相同的 ACK包 通常是三个相同的ACK它会判断某个数据包丢失并立即重发丢失的数据而不需要等待超时。 例如接收方连续发送 ACK1001 表示丢失了 1001-2000 这一段数据发送方在收到三次相同的 ACK 后就会立即重发丢失的数据。
特性超时重传快重传触发条件基于 超时如果ACK没有在规定时间内到达重传数据包基于 重复ACK如果收到相同的ACK 3次认为数据丢失重传延迟可能会有较大的延迟直到超时发生快速重传几乎没有延迟适用场景适用于较严重的丢包或网络延迟情况适用于轻度丢包或偶尔的网络问题网络负载无额外负载只有超时机制的计算会产生重复的ACK包增加额外的网络开销性能影响因为依赖超时机制延迟较大可能导致吞吐量下降快速恢复丢失数据提高吞吐量但在极端丢包情况下不太有效
4. 延迟应答
在 TCP协议 中每当接收方收到一个数据包时它通常会立即向发送方返回一个 ACK包以确认数据的接收。然而频繁地发送 ACK包 会导致网络中出现大量的小数据包这些包虽然包含确认信息但对数据传输并无实际贡献。
为了优化这个过程TCP允许接收方 延迟ACK的发送并在适当的时机发送一个 合并的ACK包。这种做法减少了单独 ACK包 的数量提高了网络的效率。
延迟ACK接收方在收到数据后会延迟一段时间来决定是否发送 ACK包。合并ACK包如果接收方接收了多个数据包它会在一个 ACK包 中确认多个数据包的接收而不是对每个数据包都发送一个独立的 ACK包。最大延迟时间接收方通常会在收到数据包后的 200ms 内发送一个 ACK包。如果这段时间内没有收到新的数据接收方会立即发送确认包。特殊情况下的例外如果接收方的窗口已经满了或者接收方发送了数据包例如 TCP的双向数据流它会立即发送 ACK包以确认收到的数据。 编程时调用recv read尽快将缓冲区中的数据拿走就能保证延迟应答返回的窗口能够更大。 5. 拥塞控制机制
拥塞控制Congestion Control是 TCP协议 中的一个关键机制旨在避免网络过载确保数据流的稳定和高效传输。TCP通过动态调整数据的发送速率来避免网络的拥塞和资源浪费从而保证高效的数据传输。
慢启动Slow Start慢启动是TCP连接开始时的一个阶段用于避免过快的开始发送数据导致网络拥塞。 在初始阶段发送方的 拥塞窗口cwnd从1个MSS最大报文段大小开始。每收到一个 ACK 包发送方会将 拥塞窗口增加1MSS表现为指数增长。这意味着随着每个往返时间RTT发送方可以发送的未确认数据量将以指数级增长。慢启动持续直到拥塞窗口达到某个阈值慢启动阈值 ssthresh然后进入 拥塞避免 阶段。 拥塞避免Congestion Avoidance当拥塞窗口达到慢启动阈值后TCP进入 拥塞避免 阶段开始减少拥塞窗口的增长速度避免网络拥塞。 在 拥塞避免 阶段 拥塞窗口的增长不再是指数级的而是以 线性 增长的方式增长。每个RTT周期窗口大小增加1MSS。这一方式通过减缓发送速率的增长避免在网络负载较高时过快增加发送数据减少了网络拥塞的发生。 快重传见第三小节。快恢复Fast Recovery快恢复机制和 快重传 一起工作确保丢包发生后能够快速恢复数据传输避免过度减少发送速率。 在 快重传 触发后发送方不再像 慢启动 那样将拥塞窗口重置为1而是将拥塞窗口减半并开始继续发送数据。快恢复旨在避免丢包后立即回到慢启动阶段而是通过减少窗口大小进行较为平缓的恢复。 滑动窗口大小 Min(接受窗口拥塞窗口) **类别 **机制说明可靠性校验和用于确保数据在传输过程中未被篡改或损坏。序列号按序到达保证数据包按照发送顺序到达接收方。确认应答接收方通过ACK包确认收到的数据确保数据传输的可靠性。超时重发如果数据包未在超时时间内得到确认发送方会重传数据。连接管理管理TCP连接的建立、维持和关闭确保连接的可靠性。流量控制控制发送速率防止接收方缓冲区溢出。拥塞控制防止网络过载调整发送速率以避免网络拥塞。提高性能滑动窗口允许发送方在接收到部分确认时继续发送数据提高传输效率。快速重传通过连续收到重复ACK包触发重传减少丢包后的延迟。延迟应答延迟发送ACK包减少网络中小数据包的数量提高带宽利用率。捎带应答将多个数据包的ACK合并成一个ACK包从而减少ACK包的数量提高效率。
4网络通信模型
1. 面向字节流
面向字节流 是 TCP 协议的传输方式数据传输以 字节流 的形式进行不保留数据的边界或结构。 特点 数据流式传输TCP将数据作为一个连续的字节流传输发送方和接收方都不关心数据的分包和重组。无论数据包有多大接收方都按字节顺序逐个接收。 可靠性由于 TCP协议 是面向连接的协议它提供 可靠传输通过 确认应答、重传机制 和 顺序控制 来确保数据的完整性和顺序。 无边界在字节流模型中数据的边界例如消息的结束是由应用层来定义的。传输层协议TCP不会干预数据的划分数据流的划分由应用层程序来处理。 顺序保证TCP提供 顺序保证即接收方会按照发送方发送的顺序接收数据即使中途数据包丢失或顺序乱了TCP会自动进行重传并确保顺序正确。 优点 顺序可靠TCP会确保字节按顺序到达且在传输过程中不会丢失。 流量控制通过 滑动窗口 和 拥塞控制TCP能够有效管理数据流的发送速率防止网络过载。 缺点 相对较慢由于TCP需要进行连接管理、数据重传、流量控制等处理导致其在实时性和效率方面不如某些无连接协议如UDP。 较高的开销每个连接的建立和维护需要消耗一定的资源适合需要高可靠性的数据传输但不适合实时性要求很高的应用。
2. 面向数据报
面向数据报 是 UDP 协议的传输方式数据传输是以 数据报 的形式进行数据包是独立的每个数据报都有自己的完整信息接收方将按各自的数据报接收。 特点 无连接性UDP是一个无连接的协议它不需要在通信之前建立连接。每个数据报即UDP数据包是独立的发送方可以随时发送数据报接收方也不需要确认收到的数据。 独立性每个 UDP数据报 都包含完整的目的地址信息包括源地址和目标地址并且数据报的大小是有限的。接收方在接收时会将每个数据报独立处理。 没有保证UDP并不保证数据的可靠性它不进行数据确认也不保证数据的顺序。数据报可能会丢失、重复或者顺序错乱。 应用层处理UDP的应用层需要自己处理丢包、数据重传和顺序问题。UDP提供一种简单而快速的数据传输方式适用于对延迟要求高且能容忍丢包的应用如实时视频流、在线游戏等。 优点 低延迟由于没有连接建立和确认机制UDP适用于对实时性要求高的应用。 轻量级UDP的协议开销比TCP小不需要维护连接或执行复杂的拥塞控制、流量控制等操作。 缺点 不可靠UDP不提供数据的可靠性保障数据可能丢失或乱序到达应用层需要自行处理。 无顺序保证UDP无法保证数据包的顺序接收方收到的顺序可能与发送方发送的顺序不同。
5粘包问题
1. 粘包问题
粘包问题 是 TCP协议 中的一种常见问题特别是在 面向字节流 的通信中。由于 TCP 是一个 面向字节流 的协议它不会在数据之间加上分隔符来标识消息的边界导致接收方无法直接知道一个完整的数据包的边界。这种情况称为 粘包。
粘包 是指多个应用层的数据包被发送方合并成一个大的数据包进行传输而接收方不能区分原本的多个数据包。接收方通常需要通过一定的规则如包长、特定的分隔符来从字节流中拆分数据。 粘包问题的原因 TCP是字节流协议在TCP中数据是作为连续的字节流传输的发送的数据并没有边界。发送方可以将多个小数据包拼接在一起发送给接收方而接收方无法直接知道数据包的结束位置。 数据合并在发送过程中多个小数据包可能被合并为一个数据包发送出去这种情况被称为 粘包。尤其是在网络传输中可能由于系统的缓冲区、数据传输过程中的合并等原因多个消息会被打包成一个大的数据包一起发送。 数据分割由于TCP协议的 流控制 和 拥塞控制 机制发送的数据并不一定会按发送的顺序或固定大小来传输接收方可能会一次接收到多个分段的数据包导致接收方无法正确区分每个独立的数据包。 粘包问题的表现 多个数据包合并多个应用层的消息在传输时合并成一个数据包接收方无法知道每个消息的边界。 数据错乱由于消息的边界无法识别接收方可能会误把两个消息的内容拼接到一起导致应用层数据解析错误。
2. 粘包和拆包的关系
粘包 和 拆包 是两个常见的网络通信问题
粘包多个数据包合并成一个大数据包发送到接收方接收方无法识别每个数据包的边界。拆包一个大的数据包被拆成多个小的数据包发送给接收方接收方需要能够正确重组这些数据包。
3. 解决粘包问题的方法
为了防止或解决粘包问题通常有以下几种方法 固定长度协议 最简单的方法是使用 固定长度的消息。每次发送的数据包长度都是固定的这样接收方就可以按照固定的字节数来分割数据包。 优点简单明了接收方按固定长度读取数据即可。 缺点不灵活数据包长度必须预先确定浪费带宽无法处理变长的数据。 消息分隔符 通过在每个数据包的结尾添加一个特定的分隔符如 ‘\n’、‘\0’、‘\r\n’ 或者自定义的标识符来标识数据包的边界。 优点非常简单且直观。 缺点分隔符可能会与数据本身重复导致误解析或数据错误需要额外的处理来避免分隔符与数据冲突。 数据包头部包含数据长度 这是最常见的解决粘包问题的方法。通过在每个数据包的 头部 包含一个 数据包的长度字段接收方通过这个字段来确定数据的边界。 实现方法 发送方在每个数据包的头部加上一个字段记录消息的 长度。 接收方读取头部的长度字段然后按照这个长度读取相应的数据包。 优点 无论数据包的内容多大或多小都可以通过长度字段来识别数据包的边界。常见于 HTTP、FTP、MQTT、TCP流协议 等应用中。 缺点增加了每个数据包的开销因为每个数据包需要包含额外的长度字段。 举例 发送数据时在每个数据包头部添加一个 固定大小的字段记录数据的长度。比如发送一个数据包 {长度字段4字节 数据内容}接收方先读取 长度字段4字节再读取指定长度的 数据内容。 分包和合包控制基于应用协议 这种方法通过协议中的规则来明确如何划分和合并数据包。例如在 HTTP协议 中头部字段如 Content-Length 或 Transfer-Encoding指示了数据体的大小接收方可以根据这些字段来判断数据包的结束。 优点适用于变长数据的处理能解决不同数据包大小的问题。 缺点需要应用层协议的支持。 举例在 HTTP/1.1 协议中Content-Length 头字段标明了消息体的长度接收方根据该字段的值来读取数据。
7) TCP异常
1. 进程终止
当进程终止时相关的 TCP连接 会被释放但实际上在 进程终止 的情况下TCP连接的断开行为和正常的连接关闭并没有太大区别。
释放文件描述符当一个进程结束时操作系统会自动关闭进程打开的所有文件描述符包括套接字描述符。套接字一旦关闭TCP连接就会被终止。发送FIN正常关闭如果进程是通过正常关闭连接的方式退出TCP会发送 FIN 报文段来通知对方连接将被关闭。接收方收到 FIN 后会回送一个 ACK并且也会执行连接的关闭操作。和正常关闭没有区别当进程退出时它仍然会按照 TCP协议 的标准流程四次挥手来优雅地关闭连接。系统会通过 FIN 关闭连接并不会直接丢弃连接状态。
2. 机器重启
机器重启 会导致与 进程终止 类似的情况因为在重启过程中所有的 TCP连接 都会丢失。
释放连接状态在计算机重启时所有正在进行的连接都会被终止。TCP连接的状态会丢失操作系统会关闭所有的套接字释放网络资源。TCP连接断开类似进程终止的情况连接会被释放发送 FIN 的过程会根据具体的连接状态进行处理。不会丢失数据如果有未确认的数据TCP协议会确保在重启之前通过重传进行可靠的传输。
3. 机器掉电/网线断开
机器掉电或网线断开 的情况比 进程终止 和 机器重启 更复杂。因为它属于 物理层 或 链路层 的问题导致一方与另一方的连接断开而这种断开并不会立即被另一方感知。
接收端认为连接仍在在机器掉电或网线断开后接收方无法立即得知连接已经断开因为 TCP 协议不会立即检测到物理连接的丢失。接收方可能会认为连接仍然是有效的。写操作时检测连接丢失当接收端尝试发送数据写操作时它会发现连接已经中断因为它无法向对方发送数据。此时接收端会收到一个 RST重置报文表示连接异常被强制关闭。TCP的保活机制即使接收端没有主动写入操作TCP协议本身有一个 保活机制。保活机制通过定期发送 探测包 来询问连接的另一方是否仍然存在。如果对方没有响应这时TCP连接会被认为已丢失连接会被释放接收方会收到 RST 包。 探测包keep-alive probes通常是小的数据包如果对方没有回应连接会被认为不可用并被强制关闭。TCP保活定时器根据不同操作系统的实现TCP保活定时器会在连接空闲一段时间后启动并开始定期发送保活探测包。如果对方没有响应连接会被释放。
6网络工具
1.网络状态 netstat命令行工具用于显示网络连接、路由表、接口统计信息、伪连接即 UNIX 域套接字等信息。它在系统管理和故障排查中非常有用尤其是在需要查看网络活动和调试网络问题时。 netstat [选项] netstat -a-a显示所有连接包括监听状态和已连接的连接。-t显示TCP连接。-u显示UDP连接。-n显示IP地址和端口号而不是进行域名解析。用于快速查看数字地址。-l仅显示在监听状态的服务端口。-p显示与每个连接相关的进程信息需要 root 权限-r显示路由表。-i显示网络接口统计信息。-s显示网络统计数据包括TCP、UDP、ICMP等协议的统计信息。 pidofpidof 是一个在 Linux 系统中用来查找指定程序或进程的 PIDProcess ID进程ID 的命令。它返回的是程序或进程的 ID用于管理和监控正在运行的进程。 pidof process_name //查找 nginx 进程的 PID
pidof nginx process_name要查找的进程的名称或可执行文件的名称。
