# 应用层
在网络通信的层次结构中,应用层起着核心作用,它提供了用户与网络服务交互的平台。开发者可以依据具体的应用需求,实现定制化的逻辑和功能,使得网络服务在隐藏了底层复杂性的同时,能够灵活适应多样化的应用场景。
应用层包含了多种高级网络通信协议,如 HTTP 协议用于网页浏览、SMTP 协议用于电子邮件的发送、FTP 协议用于文件的传输等。这些协议确立了数据交换的标准格式和交互规则,促进了不同系统和程序之间的无缝通信。在众多协议中,HTTP 协议因其在 Web 开发中的广泛应用而尤为关键,它定义了客户端与服务器之间请求和响应的通信机制。
# HTTP 的概述
在 1989 年,瑞士 CERN 的蒂姆・伯纳斯 - 李开创性地发展了超链接文档技术,奠定了 HTTP/Web 技术的基础。这一技术的进步在 1994 年得到了进一步的推动,当时伯纳斯 - 李在互联网大会上促成了 W3C 的成立,为互联网的快速发展注入了新的活力。
作为互联网资源访问不可或缺的三要素之一,HTTP 协议是深入理解 Web 开发不可或缺的部分。掌握 HTTP 协议的工作原理是成为一名合格 Web 开发者的前提。
HTTP 协议作为应用层的核心协议,其主要功能是实现网络上客户端与服务器之间的超文本数据传输。这一传输机制依赖于精心构建的 HTTP 请求和响应报文。客户端发出的请求报文和服务器发出的响应报文共同构成了 HTTP 通信的基础。
# HTTP 请求
在构建 HTTP 请求时,生成的数据包被称为 HTTP 请求报文,它由四个主要部分组成:请求行、请求头、空行以及请求体。请求行指定了请求的方法、资源的 URI 和 HTTP 的版本。请求头则是一系列的属性,用于进一步描述请求的上下文。尽管请求头和请求体并非总是必需的,但它们之间的空行是必要的,它作为一个分隔符,清晰地界定了请求头的结束。请求体本身是一个可选字段,用于承载发送给服务器的数据,例如用户提交的表单信息或 API 请求的数据。
GET / HTTP/1.1 | |
Host: www.cskaoyan.com | |
Connection: keep-alive | |
Upgrade-Insecure-Requests: 1 | |
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 | |
Accept: text/html,application/xhtml+xml,application/xml; | |
Accept-Encoding: gzip, deflate | |
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 | |
Cookie: __yjs_duid=1_94c0d6c26a48d04ztHBDp1OrzJxavJbibLH2u7JlFEirZPMlmtowns; | |
正文 |
GET /forum.php HTTP/1.1 | |
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 | |
Accept-Encoding: gzip, deflate | |
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 | |
Cache-Control: max-age=0 | |
Connection: keep-alive | |
Cookie: cZBD_2132_saltkey=khv7XrhX; cZBD_2132_lastvisit=1711412144; Hm_lvt_5f3c4e32676aacc710ede84276010d9b=1710550720,1711415747,1711440679; cZBD_2132_sid=mvlLkN; cZBD_2132_lastact=1711440771%09forum.php%09; Hm_lpvt_5f3c4e32676aacc710ede84276010d9b=1711440771 | |
Host: cskaoyan.com | |
Upgrade-Insecure-Requests: 1 | |
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 | |
正文 |
# 请求行
在 HTTP 协议中,请求行是每个请求的起始行,它由请求方法、请求资源和请求协议三个基本元素组成。
GET / HTTP/1.1 |
请求方法:请求方法定义了客户端希望对服务器执行的动作。最常见的请求方法包括 GET 和 POST。GET 方法主要用于从服务器检索数据,而 POST 方法用于向服务器提交数据。这两种方法在语义上存在明显的区别。尽管 GET 和 POST 请求在参数的传递上有所不同,但这并不是它们之间的本质区别,而是浏览器的默认行为所导致的差异。
除了 GET 和 POST,还有一些其他的请求方法,例如:
- PUT:用于上传或更新服务器上的资源。
- DELETE:用于删除服务器上的资源。
- HEAD:用于获取资源的响应头信息,但不包括响应体。
- OPTIONS:用于列出目标资源所支持的 HTTP 方法,或用于跨域访问控制(CORS)的预检请求。
URL:URL(统一资源定位符)是互联网上资源的地址,它由协议、域名或 IP 地址、端口号(可选)、服务器内部路径和参数组成。例如, https://www.baidu.com/s?rsv_idx=2&hisfilter=1
和 http://101.43.69.31:8080/#/login?redirect=%2Fdashboard
都是 URL 的实例。URL 中的服务器内部路径和参数是服务器用来识别资源和用户请求的关键信息。
请求资源:请求资源是 URL 中指定给服务器的部分,它是用户想要访问或操作的特定资源的标识。不同的资源路径指示服务器提供不同的内容或服务。
请求协议:HTTP 协议的版本定义了客户端和服务器之间通信的规则。目前最常用的版本是 HTTP/1.1,它支持持久连接,允许在一个 TCP 连接上发送多个 HTTP 请求,这与 HTTP/1.0 相比,后者不支持持久连接。持久连接的使用显著提高了网络访问的效率。
# 请求头
请求头是 HTTP 请求的一部分,包含了客户端发送给服务器的元数据。虽然 HTTP 协议定义了众多的请求头字段,但在实际应用中,只有一部分被频繁使用。
Accept 请求头: Accept
请求头用于告知服务器,客户端能够处理的 MIME 类型。MIME 类型是一种资源分类方式,格式为 “大类型 / 小类型”,例如 text/html
、 image/jpeg
等。这个请求头对于确保客户端能够正确解析服务器响应的数据至关重要。
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 |
Accept-Charset 请求头: Accept-Charset
请求头指示客户端支持的字符集,如 UTF-8。这对于处理多语言内容和确保字符正确显示非常重要。
UTF-8 |
Accept-Encoding 请求头: Accept-Encoding
请求头列出了客户端能够解码的数据编码方式,如 gzip。这允许服务器根据客户端的能力选择最合适的压缩格式,以优化数据传输效率。
Accept-Encoding: gzip, deflate, br, zstd |
Accept-Language 请求头: Accept-Language
请求头表达了客户端对语言的偏好,格式为 语言-国家
,如 zh-CN
。当服务器能够提供多种语言版本的内容时,这个请求头就显得尤为重要。
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 |
Referer 请求头 : Referer
请求头包含了一个 URL,指示用户是从哪个页面发起了当前请求。这个请求头可以用于防盗链机制,以及分析用户访问路径。
Content-Type 请求头 : Content-Type
请求头指定了请求体的 MIME 类型,这对于服务器正确解析请求体中的数据类型至关重要。
Content-Length 请求头: Content-Length
请求头表明了请求体的长度,以字节为单位。这个信息对于服务器正确处理请求体内容是必要的。
User-Agent 请求头: User-Agent
请求头提供了客户端的浏览器类型和操作系统信息,有助于服务器识别客户端的能力。
Date 请求头: Date
请求头记录了请求发送的时间,格式遵循 GMT 标准时间。
Connection 请求头: Connection
请求头指示了客户端对持久连接的需求。例如, Keep-Alive
表示客户端希望保持连接,而 close
则表示请求完成后关闭连接。
If-Modified-Since 请求头: If-Modified-Since
请求头用于实现缓存控制,它包含了客户端缓存资源的最后修改时间。如果服务器资源的最后修改时间与之一致,服务器可以决定不发送重复内容,而是让客户端使用本地缓存。
Cookie 请求头: Cookie
请求头是 HTTP 请求中极其重要的部分,它用于携带客户端的会话信息,如登录状态,从而提供更安全和个性化的服务。
Host 请求头: Host
请求头指定了请求的目标主机和端口,这对于访问配置了多个虚拟主机的服务器尤为重要。
# 空行
仅做标识使用
# 请求正文 / 请求体
请求体的作用:请求体承载了客户端需要传递给服务器的数据信息。这一部分可以包含大量的数据,使其成为提交复杂数据集的理想选择。
数据传输示例:在多种应用场景中,请求体发挥着关键作用。例如,当客户端需要向服务器提交一个文件时,文件的内容可以被放置在请求体中,从而实现文件的上传。此外,当用户需要安全地传输敏感信息,如登录凭据或个人数据时,这些信息也可以通过请求体进行加密后发送,以确保数据的保密性和完整性。
技术实现:请求体的大小和内容类型由 Content-Type
和 Content-Length
请求头指定。 Content-Type
指示了请求体中数据的媒体类型,而 Content-Length
则表明了请求体的长度。这些信息帮助服务器正确解析和处理请求体中的数据。
安全性考虑:在涉及敏感信息传输时,使用 HTTPS 协议加密整个 HTTP 请求,包括请求体,是保障数据传输安全的最佳实践。此外,对于需要额外安全性的场景,如金融交易或个人身份验证,可以采用更高级的加密技术和安全协议。
# HTTP 响应
在 HTTP 通信过程中,服务器发出的响应被称为 HTTP 响应报文,它由四个主要部分组成:响应行、响应头、空行和响应体。响应行指定了 HTTP 协议的版本、响应状态码及状态消息。响应头则包含了描述响应内容的一系列属性。尽管响应头和响应体并非总是必需的,但它们之间的空行是必要的,它作为一个分隔符,清晰地界定了响应头的结束。响应体本身是一个可选字段,用于承载服务器返回给客户端的数据。
# 响应行
//协议 状态码 原因短语 | |
HTTP/1.1 200 OK |
版本协议:HTTP/1.1
状态码 | 状态码英文名称 | 中文描述 |
---|---|---|
100 | Continue | 继续。客户端应继续其请求 |
101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到 HTTP 的新版本协议 |
102 | Processing | 服务器已收到并正在处理该请求,但当前没有响应可用 |
103 | Early Hints | 此状态代码主要用于与 Link 链接头一起使用,以允许用户代理在服务器准备响应阶段时开始预加载 preloading 资源。 |
200 | OK | 请求成功。一般用于 GET 与 POST 请求 |
201 | Created | 已创建。成功请求并创建了新的资源 |
202 | Accepted | 已接受。已经接受请求,但未处理完成 |
203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的 meta 信息不在原始的服务器,而是一个副本 |
204 | No Content | 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档 |
205 | Reset Content | 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域 |
206 | Partial Content | 部分内容。服务器成功处理了部分 GET 请求 |
207 | Multi-Status | 对于多个状态代码都可能合适的情况,传输有关多个资源的信息。 |
208 | Already Reported | 在 DAV 里面使用 <dav:propstat> 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。 |
226 | IM Used | 服务器已经完成了对资源的 GET 请求,并且响应是对当前实例应用的一个或多个实例操作结果的表示。 |
300 | Multiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择 |
301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新 URI,返回信息会包括新的 URI,浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替 |
302 | Found | 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有 URI |
303 | See Other | 查看其它地址。与 301 类似。使用 GET 和 POST 请求查看 |
304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问,已被弃用。 |
306 | Unused | 已经被废弃的 HTTP 状态码 |
307 | Temporary Redirect | 服务器发送此响应,以指示客户端使用在前一个请求中使用的相同方法在另一个 URI 上获取所请求的资源。这与 302 Found HTTP 响应代码具有相同的语义,但用户代理 不能 更改所使用的 HTTP 方法:如果在第一个请求中使用了 POST ,则在第二个请求中必须使用 POST |
308 | Permanent Redirect | 这意味着资源现在永久位于由 Location: HTTP Response 标头指定的另一个 URI。这与 301 Moved Permanently HTTP 响应代码具有相同的语义,但用户代理不能更改所使用的 HTTP 方法:如果在第一个请求中使用 POST ,则必须在第二个请求中使用 POST 。 |
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 |
401 | Unauthorized | 请求要求用户的身份认证 |
402 | Payment Required | 保留,将来使用 |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 |
404 | Not Found | 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置 "您所请求的资源无法找到" 的个性页面 |
405 | Method Not Allowed | 客户端请求中的方法被禁止 |
406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
407 | Proxy Authentication Required | 请求要求代理的身份认证,与 401 类似,但请求者应当使用代理进行授权 |
408 | Request Time-out | 服务器等待客户端发送的请求时间过长,超时 |
409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码,服务器处理请求时发生了冲突 |
410 | Gone | 客户端请求的资源已经不存在。410 不同于 404,如果资源以前有现在被永久删除了可使用 410 代码,网站设计人员可通过 301 代码指定资源的新位置 |
411 | Length Required | 服务器无法处理客户端发送的不带 Content-Length 的请求信息 |
412 | Precondition Failed | 客户端请求信息的先决条件错误 |
413 | Request Entity Too Large | 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个 Retry-After 的响应信息 |
414 | Request-URI Too Large | 请求的 URI 过长(URI 通常为网址),服务器无法处理 |
415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
416 | Requested range not satisfiable | 客户端请求的范围无效 |
417 | Expectation Failed | 服务器无法满足请求头中 Expect 字段指定的预期行为。 |
418 | I'm a teapot | 状态码 418 实际上是一个愚人节玩笑。它在 RFC 2324 中定义,该 RFC 是一个关于超文本咖啡壶控制协议(HTCPCP)的笑话文件。在这个笑话中,418 状态码是作为一个玩笑加入到 HTTP 协议中的。 |
421 | Misdirected Request | 请求被定向到无法生成响应的服务器。这可以由未配置为针对请求 URI 中包含的方案和权限组合生成响应的服务器发送。 |
422 | Unprocessable Entity | 请求格式正确,但由于语义错误而无法遵循。 |
423 | Locked | 正在访问的资源已锁定。 |
424 | Failed Dependency | 由于前一个请求失败,请求失败。 |
425 | Too Early | 表示服务器不愿意冒险处理可能被重播的请求。 |
426 | Upgrade Required | 服务器拒绝使用当前协议执行请求,但在客户端升级到其他协议后可能愿意这样做。 服务端发送带有 Upgrade 字段的 426 响应 来表明它所需的协议(们)。 |
428 | Precondition Required | 源服务器要求请求是有条件的。此响应旨在防止 ' 丢失更新 ' 问题,即当第三方修改服务器上的状态时,客户端 GET 获取资源的状态,对其进行修改并将其 PUT 放回服务器,从而导致冲突。 |
429 | Too Many Requests | 用户在给定的时间内发送了太多请求("限制请求速率") |
431 | Request Header Fields Too Large | 服务器不愿意处理请求,因为其头字段太大。在减小请求头字段的大小后,可以重新提交请求。 |
451 | Unavailable For Legal Reasons | 用户代理请求了无法合法提供的资源,例如政府审查的网页。 |
500 | Internal Server Error | 服务器内部错误,无法完成请求 |
501 | Not Implemented | 服务器不支持请求的功能,无法完成请求 |
502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应 |
503 | Service Unavailable | 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中 |
504 | Gateway Time-out | 充当网关或代理的服务器,未及时从远端服务器获取请求 |
505 | HTTP Version not supported | 服务器不支持请求的 HTTP 协议的版本,无法完成处理 |
506 | Variant Also Negotiates | 服务器存在内部配置错误:所选的变体资源被配置为参与透明内容协商本身,因此不是协商过程中的适当终点。 |
507 | Insufficient Storage | 无法在资源上执行该方法,因为服务器无法存储成功完成请求所需的表示。 |
508 | Loop Detected | 服务器在处理请求时检测到无限循环。 |
510 | Not Extended | 服务器需要对请求进行进一步扩展才能完成请求。 |
511 | Network Authentication Required | 指示客户端需要进行身份验证才能获得网络访问权限。 |
原因短语:成功或者失败(不重要,从语法上可以随意写)
# 响应头
Location 响应头: Location
响应头指示新的资源位置,通常与重定向状态码(如 301 或 302)一起使用,指引浏览器向指定的新地址重新发起请求。
Server 响应头: Server
响应头表明服务器的软件类型,例如 Apache Tomcat
,这有助于客户端了解服务器的类型和版本。
Content-Encoding 响应头: Content-Encoding
响应头说明了服务器发送的数据采用的编码类型,如 gzip
,这指示客户端需要使用相应的解码方式来处理接收到的数据。
Content-Type 响应头: Content-Type
响应头指定了服务器发送内容的 MIME 类型,例如 text/html
,这告诉客户端响应体的媒体类型。
Content-Length 响应头: Content-Length
响应头告知浏览器响应体的长度,以字节为单位,这有助于客户端正确解析响应体。
Content-Language 响应头: Content-Language
响应头指示服务发送文本的语言,如 zh-cn
,这有助于客户端根据用户的语言偏好显示内容。
Last-Modified 响应头: Last-Modified
响应头提供了资源的最后修改时间,这可以用于缓存控制和条件请求。
Refresh 响应头: Refresh
响应头指示客户端刷新频率,单位是秒,这可以用于实现页面自动刷新或重定向。
Content-Disposition 响应头: Content-Disposition
响应头通常与文件下载相关,指示客户端应如何处理响应体,例如作为附件保存。
Set-Cookie 响应头: Set-Cookie
响应头用于服务器端发送 Cookie,用于标识用户信息,并在用户下次访问时携带该 Cookie。
Cache-Control 响应头: Cache-Control
响应头用于控制响应的缓存行为,例如 no-cache
指示客户端不应缓存响应内容。
Connection 响应头: Connection
响应头指示连接的使用情况, close
表示请求完成后关闭连接,而 Keep-Alive
表示保持连接。
Date 响应头: Date
响应头记录了响应发送的时间,格式遵循 GMT 标准时间。
# 空行
标识使用
# 响应正文 / 响应体
响应体承载着服务器响应的核心内容,它可以包含文本数据或二进制数据。通过响应头中的 Content-Type
字段,客户端能够识别响应体的类型,例如 text/html
用于网页内容,而 image/png
用于图片资源。 Content-Length
字段进一步提供了响应体的长度信息,允许客户端根据这一长度来分配内存或进行流式处理。这些信息共同确保了客户端能够正确解析和利用服务器发送的数据。
# HTTPS
HTTP 协议以其简单和灵活的特性,在网络通信中发挥着重要作用。然而,它也存在一些明显的不足之处,具体包括:
- 数据安全性问题:HTTP 协议传输的数据未经过加密,这意味着数据在传输过程中可能被第三方窃听或截取。
- 身份验证缺失:HTTP 协议不包含任何机制来验证通信双方的身份,这可能导致通信过程中出现伪装或冒充的风险。
- 数据完整性无法保证:由于缺乏完整性校验,HTTP 协议无法确保传输的数据在传输过程中未被篡改或损坏。
为了解决这些问题,HTTPS 协议被引入。HTTPS 通过以下方式增强了安全性:
- 加密算法:使用 SSL/TLS 等加密协议对数据进行加密,确保数据在传输过程中的机密性。
- 证书:利用数字证书验证服务器和(可选的)客户端的身份,防止伪装和中间人攻击。
- 完整性保障:通过消息完整性检查机制,如消息摘要和数字签名,确保数据在传输过程中未被篡改。
# 抓包
在进行网络通信分析时,抓包技术能够帮助我们捕获并审视 HTTP 请求的详细过程。以下是我们在分析过程中应当关注的关键信息:
- 请求的成功状态:通过检查状态码,如
200
,来确认请求是否成功。 - 请求方法的一致性:确保使用的请求方法(如 GET 或 POST)符合预期。
- IP 地址的准确性:验证请求是否被发送到了正确的目标 IP 地址。
- 端口号的匹配性:检查端口号是否与预期的请求端口相符。
- 资源路径的正确性:确认请求指向的服务器内部路径或资源路径无误。
- 请求参数的准确性:检查请求中包含的参数是否准确无误。
- 响应数据的符合性:分析服务器返回的数据是否与预期相符。
通过使用 Chrome 浏览器的开发者工具或其他专业的抓包工具,我们可以有效地监控和分析网络请求,从而获得这些关键信息。这种分析对于调试网络应用、优化性能和确保数据安全至关重要。
# 传输层
在网络通信的层次模型中,传输层作为连接应用层与网络其余部分的桥梁,提供了一系列通信服务。它既是面向通信的顶层,也是用户访问网络服务的底层。传输层的核心功能是实现不同主机上运行的应用程序之间的数据交换。
在这一层中,TCP 和 UDP 是两个至关重要的协议。TCP 通过建立连接、数据排序和错误检测机制,提供了一种可靠、有序的数据传输服务,尽管这可能会牺牲一定的传输速度。相对地,UDP 作为一种无连接的协议,以其高效的传输速率著称,但在数据的可靠性和顺序性方面不作保证。这两种协议根据不同的应用场景和需求,提供了灵活的选择。
# TCP
# TCP 的特点
传输控制协议(TCP)是网络通信体系中的核心协议,运行在传输层,旨在网络层提供的不可靠服务基础上,实现一个可靠、面向连接、全双工的端到端通信。TCP 的端到端性质表明,其通信是在两台主机的逻辑层面上直接进行的,这与网络层的逐跳路由和数据链路层的帧转发形成了鲜明对比。在 TCP 的端到端通信中,数据传输是连续且直接的,而网络层和数据链路层则负责处理数据在网络中的路由和帧的传输。TCP 通过这种方式,确保了数据在源主机和目的主机之间可靠地传输,而无需关注底层网络的具体传输细节。
# TCP 报文头部
在网络协议栈的数据传递过程中,应用层生成的数据在传输至传输层时,传输层会将其完整地封装在自己的数据单元内,这部分数据被称为有效载荷。
# TCP 头部格式
在 TCP 协议中,当数据从应用层传递到传输层,TCP 会在这些数据前添加特定的头部信息,创建一个 TCP 段。TCP 头部携带了源端口、目的端口、序列号、确认号等关键信息,这些信息对于建立端到端的连接、维护数据传输的顺序和完整性、以及流量控制和拥塞控制等机制至关重要。
# 各字段意义
以下是对 TCP 头部中各个字段的详细解释:
- 源端口和目的端口:分别记录发送请求的主机的发送端口和目标主机的接收端口,用于标识通信的两端。
- 序号(Seq):TCP 为整个传输过程中的每个字节进行编号,起始编号在 TCP 连接建立时随机生成,并在后续传输中递增。序号 Seq 表示本报文段所发送数据的第一个字节的编号。
- 确认号(Ack):接收方对接收到的数据进行确认,确认号表示期望收到的下一个数据字节的编号。确认位 ACK 为 1 时,确认号才有效。
- 数据偏移:指示 TCP 报文段的数据起始处距离 TCP 报文段起始处的距离,即 TCP 首部长度,最大值为 60 字节。
- 保留位:目前未用,将来可能用于其他功能,当前置为 0。
- 紧急位(URG):当 URG = 1 时,表示报文段中有紧急数据,应优先处理。
- 确认位(ACK):ACK = 1 时,确认号有效,表示确认收到的数据。
- 推送位(PSH):当 PSH = 1 时,接收方应尽快将数据传递给应用层。
- 复位位(RST):当 RST = 1 时,表示 TCP 连接出现严重错误,需要释放并重建连接。
- 同步位(SYN):SYN = 1 时,表示这是一个建立连接的请求。
- 终止位(FIN):FIN = 1 时,表示数据发送完毕,请求释放连接。
- 窗口大小:表示发送端的接收窗口所能允许接受到的对方发送的数据量。
- 效验和:检验首部和数据部分的正确性。
- 紧急指针:仅在 URG = 1 时有意义,指出紧急数据的字节数。
- 选项:长度可变,常见的选项包括最大段大小(MSS),描述后续希望接收到的报文段的最大值。
# 可靠传输
TCP 协议的可靠性主要依赖于序号、确认机制以及重传机制。
序号机制:TCP 通过序号机制确保数据的有序传输。每个字节的数据流都被分配一个唯一的序列号,该序列号从连接建立时随机生成的初始序列号(ISN)开始,并随着数据的发送逐字节递增。每个 TCP 报文段的序号字段指明了该段中第一个字节的序列号,这使得接收方能够正确地重新组装收到的数据。
确认机制:TCP 使用累积确认来简化确认过程。接收方在收到报文段后,发送一个 ACK 确认报文,其中的确认号表示期望收到的下一个字节的序列号。例如,如果接收方收到序号为 N 的报文段,并且该报文段包含 100 个字节的数据,接收方会发送一个确认号为 N+100 的 ACK 报文段,表明已经成功接收并期望继续接收后续数据。
重传机制:重传机制是 TCP 保证数据可靠性的关键。如果发送方在预定的超时时间内没有收到对某个报文段的确认,它会假定该报文段丢失或在网络中延迟,从而触发重传。此外,TCP 还采用快速重传策略:当接收方收到重复的报文段并发送了三个相同的确认号时,发送方会立即重传该数据,而不是等待超时计时器到期。
# 累积确认
在 TCP 的传输过程中,接收方会对接收到的数据进行确认。累积确认意味着当接收方发送一个确认(ACK)报文时,它确认的是从上一个已确认字节的序号开始,一直到当前确认号所指序号的所有字节。这表示一个 ACK 报文可以代表对多个报文段的确认。
# 快速重传 & 窗口机制
窗口机制:窗口机制通过发送端和接收端的窗口来控制数据流量,提高传输效率。发送端根据接收端通告的窗口大小来决定可以发送多少数据,而接收端通过 ACK 报文段中的窗口大小字段告知发送端其缓冲区的剩余容量。这有助于防止发送方发送过多数据导致接收方缓冲区溢出。
流量控制:流量控制确保发送方不会发送超出接收方处理能力的数据量。当发送方接收到确认报文时,它会根据确认号移除已成功接收的数据部分,从而调整发送窗口。
快速重传:快速重传是 TCP 协议中的一种机制,用于在检测到数据丢失时迅速采取行动。如果发送方连续收到三个相同的确认号,这表明接收方尚未收到后续的数据,而发送方可能已经丢失了该数据。在这种情况下,发送方会立即重传该数据,而不需要等待重传计时器超时。
# TCP 连接的建立和断开
# 建立 TCP 连接:三次握手
第一次握手:SYN 发送:客户端开始建立连接的过程,通过向服务器发送一个 SYN 报文段。在这个报文段中,SYN 位被设置为 1,表示这是一个建立连接的请求。客户端还会生成一个初始序列号(x),这个序列号用于后续的数据传输。这一步的目的是告知服务器客户端希望建立连接,并已准备好接收数据。
第二次握手:SYN 和 ACK 的发送:服务器接收到客户端的 SYN 报文后,如果同意建立连接,会发送一个 SYN-ACK 报文段作为响应。在这个报文段中,SYN 位和 ACK 位都被设置为 1。服务器会设置确认号为客户端的初始序列号加 1(x+1),表示对客户端 SYN 报文的确认。同时,服务器也会生成自己的初始序列号(y),并携带这个序列号在 SYN-ACK 报文段中。这一步的目的是服务器通知客户端它已准备好建立连接,并可以接收数据。
第三次握手:ACK 的发送:客户端在接收到服务器的 SYN-ACK 报文后,会发送一个 ACK 报文段作为最终确认。这个 ACK 报文段只设置 ACK 位为 1,表示对服务器 SYN-ACK 报文的确认。客户端会将确认号设置为服务器的初始序列号加 1(y+1),确认服务器的 SYN。这一步标志着 TCP 连接的建立完成,客户端和服务器都确认了对方的初始序列号,可以开始数据传输。
# 释放 TCP 连接:四次挥手
当 TCP 连接的一方完成数据发送并希望关闭连接时,会启动一个四次挥手的流程来终止连接。
第一次挥手:FIN 发送
客户端完成数据发送后,决定关闭连接。为此,客户端发送一个 FIN 报文段给服务器,其中 FIN 位被设置为 1,表示客户端已经完成发送任务,希望终止连接。这个报文段的序列号 Seq 是客户端当前的序列号。
第二次挥手:ACK 发送
服务器接收到客户端的 FIN 报文后,发送一个 ACK 报文段作为响应。服务器设置 ACK 位为 1,并将确认号设置为客户端序列号的后一个值,以确认已接收到客户端的终止请求。此时,客户端到服务器的连接已关闭,但服务器仍可以向客户端发送数据,这种状态称为半关闭。
第三次挥手:FIN 发送
服务器在完成所有数据发送后,向客户端发送一个 FIN 报文段,其中 FIN 位被设置为 1,表示服务器也准备关闭连接。这个 FIN 报文段包含服务器的当前序列号。
第四次挥手:ACK 发送
客户端接收到服务器的 FIN 报文后,发送一个 ACK 报文段作为最终确认。客户端设置 ACK 位为 1,并将确认号设置为服务器序列号的后一个值。这标志着 TCP 连接的完全关闭。
# TCP 的状态转换
TCP 连接的状态确实会随着通信双方的报文交换而变化。
TCP 连接状态变化
在 TCP 连接的生命周期中,状态会经历多个阶段,包括连接建立、数据传输、连接关闭。每个阶段都有特定的状态,如 SYN_SENT、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT 和 CLOSED。
MSL(最大报文段生存时间)
MSL 是 TCP 报文段在网络中存在的最长时间。这个时间限制确保了 TCP 报文段不会在网络中无限期地存在。不同的 TCP 实现可以设置不同的 MSL 值。
TIME_WAIT 状态和 2MSL 等待
客户端在完成连接关闭的四次挥手后,会进入 TIME_WAIT 状态,并等待 2 倍的 MSL 时间。这个等待期的原因包括:
-
确保对方收到最终 ACK:TIME_WAIT 状态确保连接的另一方有足够的时间接收到最后一个 ACK。如果服务器没有收到这个 ACK,并且第三次挥手超时,服务器可能会重新发送 FIN 报文段。客户端在 TIME_WAIT 状态可以响应这种情况,确保连接的可靠终止。
-
端口和资源的正确释放:这个等待期还允许操作系统正确地清理和释放用于连接的资源,如端口号。在 2MSL 结束后,相同的端口号可以安全地被新的连接使用,不会受到旧连接残留数据的影响。
通过 TIME_WAIT 状态和 2MSL 等待,TCP 确保了连接的可靠关闭和资源的正确释放,同时也防止了旧连接的数据干扰新的连接。
# UDP
# UDP 的特点
UDP 是一种简单高效的传输层协议,它以数据报的形式提供无连接的服务。以下是对您提供的 UDP 特性描述的改写和详细解释:
-
无连接特性:UDP 作为无连接协议,不需要在数据传输前建立连接。每个 UDP 数据报独立发送,不依赖于其他数据报。
-
低开销:UDP 的协议头部较小,仅有 8 字节,远小于 TCP 的最小 20 字节头部。这种简洁性减少了传输数据时的额外开销。
-
不保证可靠性:UDP 不提供数据传输的可靠性保证。它不进行错误检测或纠正,因此数据包可能会在传输过程中丢失、重复或乱序到达,而发送方通常不会收到相关通知。
-
缺乏拥塞控制:UDP 不实现拥塞控制机制,它以恒定的速度发送数据包,不考虑网络的当前状态。这可能导致在网络拥塞时数据包被丢弃。
-
快速传输:UDP 由于省略了连接建立、数据确认、流量控制等步骤,能够更快地开始数据传输。然而,数据包是否能够到达目的地仍然是一个开放的问题。
UDP 的这些特性使其适用于对实时性要求较高而对数据传输可靠性要求不高的应用场景,如视频流、VoIP、在线游戏和某些聊天应用。在选择 UDP 作为传输协议时,需要权衡实时性和可靠性的需求。
# UDP 报文头部
当应用层数据向下传递至传输层时,传输层将接收来自上层的数据单元,并将其完整地封装在自己的有效载荷中。
以 UDP(用户数据报协议)为例,传输层在接收到应用层数据后,会在其前添加 UDP 头部信息,形成 UDP 数据报。
UDP 头部结构相对简单,仅包含以下基本信息:
- 源端口号:标识发送方的应用层实体。
- 目的端口号:标识接收方的应用层实体。
- 长度:UDP 数据报的长度,包括 UDP 头部和有效载荷。
- 校验和:用于检测 UDP 数据报在传输过程中是否出现错误。
# 网络层
网络层作为计算机网络体系中的第三层,承担着在不同网络节点之间传输数据包的关键任务。它负责解决不同网络间的通信难题,确保数据能够高效、准确地从起点传输到终点。
在网络层中,ICMP、IGMP 和 IP 协议是其主要的协议。ICMP 负责报告网络通信中的错误和提供有关网络操作的信息。IGMP 则用于高效地管理多播通信中的组成员。而 IP 协议作为网络层的核心,不仅为网络中的设备分配唯一的地址,还负责数据包的路由和转发,确保数据能够跨越不同网络,最终到达目标目的地。
# IP 协议概述
IP 协议是网络层的基石,为 TCP 和 UDP 等传输层协议提供数据传输服务。作为一种无连接的协议,IP 协议在传输数据时不建立持久的连接,每个 IP 数据报独立处理。IP 协议提供的是尽力而为的交付服务,它不保证数据包的可靠到达。在网络条件不理想时,数据包可能会被丢弃,且 IP 层不负责重传。此外,IP 协议不保证数据包的顺序到达,不同的数据包可能沿着网络中的不同路径传输。IP 协议的无状态特性意味着它在数据传输过程中不维护状态信息,从而为各种网络应用提供了灵活的传输服务。
# IP 地址
IP 协议要求网络中的每个设备拥有一个独特的 IP 地址,该地址由 32 比特组成,相当于 4 个字节。IP 地址在网络通信中扮演着至关重要的角色,它为主机提供了一个明确的位置标识。当数据在互联网上传输时,IP 地址确保数据包能够根据指定的地址,在众多的网络设备中找到目标主机。
# ipconfig & ifconfig
ipconfig
和 ifconfig
是两款用于网络接口配置和状态查看的实用工具。在 Windows 系统中, ipconfig
命令能够展示主机的网络配置详情,如 IP 地址、子网掩码和默认网关等关键网络参数。而在 Linux 系统中, ifconfig
命令则提供了一个对应的功能,允许用户查看包括 IP 地址、掩码、广播地址和网关在内的网络接口信息。
# IP 地址分类
当我们讨论 IP 地址分类时,我们通常指的是 IPv4 地址的分类,这些地址由 32 位组成,通常按照 8 位一组进行分隔,形成我们熟知的点分十进制格式,例如 255.255.255.255
或 210.168.10.2
。
IP 地址由两部分组成:网络号和主机号。例如,在 IP 地址 210.168.10.2
中, 210.168.10
是网络号,而 2
是主机号。
IP 地址可以分为以下几类:
- A 类地址:范围从
1.0.0.0
到126.0.0.0
,网络号占用 8 位,主机号占用 24 位,每个网络可以有 1677 万多个主机。 - B 类地址:范围从
128.0.0.0
到191.255.0.0
,网络号占用 16 位,主机号占用 16 位,每个网络可以有 6 万多个主机。 - C 类地址:范围从
192.0.0.0
到223.255.255.0
,网络号占用 24 位,主机号占用 8 位,每个网络可以有 256 个主机(实际使用时减去 2 个地址,即网络地址和广播地址)。 - D 类地址:范围从
224.0.0.0
到239.255.255.255
,用于多播,不用于网络和主机的划分。 - E 类地址:范围从
240.0.0.0
到255.255.255.255
,保留用于实验和未来使用。
此外,还有两个特殊的 IP 地址概念:
- 广播 IP:用于向同一网络中的所有主机发送数据,其主机号部分全部为 1。
- 网络本身 IP:用于标识网络本身,其主机号部分全部为 0。
# 子网掩码 & CIDR
随着互联网的快速发展,传统的 ABCDE 类 IP 地址划分方式因其不够灵活和地址分配效率低下而逐渐被淘汰。取而代之的是子网划分和子网掩码,以及 CIDR(无分类域间路由选择)技术的出现。
子网掩码划分
子网掩码的引入提高了 IP 地址的利用率和灵活性。通过将 IP 地址分为三级结构:网络号、子网号和主机号,可以更有效地划分和利用 IP 地址空间。子网掩码是一个 32 位的二进制数,由连续的 1 和 0 组成,其中 1 的位数表示网络号和子网号的长度,0 则表示主机号。
例如,对于 IP 地址 43.141.6.15 和子网掩码 255.192.0.0,我们可以确定其所属类别、子网号和主机号:
- 确定 IP 地址的类别:43.141.6.15 属于 A 类地址。
- 计算子网号:将 IP 地址与子网掩码进行逐位逻辑与运算,得到子网号 43.128.0.0。
- 计算主机号:主机号是 IP 地址中未被子网掩码覆盖的部分,为 0.13.6.15。
CIDR
CIDR 技术消除了传统的 A、B、C 类网络划分,提供了更灵活的 IP 地址分配方式。CIDR 使用网络前缀和主机号来表示 IP 地址,并采用斜线符号(/)来表示网络前缀所占的位数。
例如,对于 CIDR 表示法 128.14.33.5/20:
- 网络前缀长度为 20 位,子网掩码为 11111111.11111111.11110000.00000000。
- 将 IP 地址 128.14.33.5 与子网掩码进行逻辑与运算,得到网络前缀 128.14.32.0。
- 主机号为 IP 地址中未被网络前缀覆盖的部分,为 0.0.1.5。
# 一些特殊的 IP 地址
下面是一些常见的用于特殊用途的 IP 地址:
前缀 | 用途 |
---|---|
0.0.0.0 | 作为源地址时表示本地主机 || 作为目的地址时,表示任意 IP 地址 |
127.X.X.X (127.0.0.0 127.0.0.1) | 回环地址 (127.0.0.1 是最常见以及最广泛的支持的回环地址) |
169.254.0.0 | 链路本地地址,通常出现在 DHCP 自动分配 IP 未完成时 |
255.255.255.255 | 本地网络广播地址 |
10.X.X.X | 局域网 IP 地址 |
172.16.X.X~172.31.X.X | 局域网 IP 地址 |
192.168.0.X~192.168.255.X | 局域网 IP 地址 |
# 局域网
局域网通过在有限的地理范围内连接多台主机,提供了高带宽、低延迟的网络环境,并支持有效的广播通信。局域网的一个显著优势在于其对 IP 地址的高效利用,这主要得益于 NAT 技术的应用。NAT 技术使得局域网内的多个设备能够通过单一的公网 IP 地址进行互联网访问,同时在局域网内部保留独立的私有 IP 地址。这种地址转换机制不仅优化了全球 IP 地址的分配,还为小型网络提供了灵活的网络解决方案。
前缀 | 用途 |
---|---|
10.X.X.X | 局域网 IP 地址 |
172.16.X.X~172.31.X.X | 局域网 IP 地址 |
192.168.0.X~192.168.255.X | 局域网 IP 地址 |
# IPv4 和 IPv6
IPv4(互联网协议第 4 版)
- 地址长度:IPv4 地址是 32 位长,通常以点分十进制格式表示,如
192.168.1.1
。 - 地址空间:IPv4 提供了大约 43 亿个唯一地址。随着互联网的快速发展,这一数量已经难以满足全球的需求。
IPv6(互联网协议第 6 版)
- 地址长度:IPv6 地址是 128 位长,以点分十六进制格式表示,例如
2001:0db8:85a3:0000:0000:8a2e:0370:7334
。 - 地址空间:IPv6 提供了极大的地址空间,理论上可以为地球上每个设备分配数以万亿计的 IP 地址,从而解决了 IPv4 地址耗尽的问题。
其他区别
除了地址长度和地址空间之外,IPv6 还提供了其他一些改进:
- 安全性:IPv6 在设计时就内嵌了对 IPsec(一种网络层的安全协议)的支持,从而提高了网络通信的安全性。
- 网络配置:IPv6 简化了网络配置过程,支持自动配置(如 SLAAC,即无状态地址自动配置)。
- 性能和效率:IPv6 的设计减少了路由器的头部处理开销,提高了数据传输的效率。
IPv6 是 IPv4 的改进和扩展,它不仅解决了 IPv4 面临的地址耗尽问题,还提供了更高的安全性、更简单的网络配置和管理,以及改进的性能和效率。
# IP 数据报格式
在网络通信过程中,应用层生成的数据在下传至网络层时,由 IP 协议进行封装。
以 IP 协议为例,当传输层的 UDP 或 TCP 报文传递至网络层,IP 协议会在这些报文前添加 IP 头部,从而形成 IP 数据报。IP 头部包含了源和目的 IP 地址等信息,为数据报在网络中的传输提供了必要的路由信息。传输层报文则作为 IP 数据报的有效载荷,保持其完整性,随同 IP 头部一起被传输至目的地。
IPv4 头部格式如下:
IP 头部各字段意义的详细解释:
- 版本:该字段值为 4 时代表 IPV4,值为 6 时代表 IPV6。目前广泛使用的版本为 4。
- 首部长度:指示 IP 首部的长度,最小 20 字节,最大 60 字节。这包括了固定长度的 20 字节和最多 40 字节的可选字段。
- 区分服务:此字段用于支持 QoS(服务质量)。
- 总长度:表示整个 IP 数据报的大小,包括首部和数据,单位为字节,范围 0~65535 字节。
- 标识:用于标识一个 IP 报文,当报文需要分片时,所有分片的标识字段值相同,以便在目的地重组。
- 标志:3 比特位,包括 MF(更多分片)和 DF(不分片)标志。MF = 1 表示还有更多分片,MF = 0 表示无后续分片。DF = 0 表示不允许分片,DF = 1 表示允许分片。
- 片偏移:指示当前分片在原始数据报中的相对位置,单位为 8 字节。
- 生存时间(TTL):表示数据报在网络中的生命周期。每经过一个路由器,TTL 减 1,减至 0 时数据报被丢弃。
- 协议:指出 IP 报文携带的数据使用的是哪种协议,如 UDP 或 TCP,以便目的主机的 IP 层知道将数据报上交至正确的处理协议。
- 首部效验和:用于检测 IP 首部在传输过程中是否出现错误。
- 源地址 IP:指示数据报的发送源 IP 地址。
- 目的地址 IP:指示数据报的目标 IP 地址。
# IP 报文的分片重组
在网络层,IP 协议将数据封装成 IP 数据报,随后这些数据报被传递至数据链路层,在这里它们被进一步封装成数据帧。值得注意的是,数据链路层的数据帧所承载的数据部分存在大小限制,即最大传输单元(MTU)。以以太网为例,其 MTU 通常为 1500 字节。
当 IP 数据报的大小超出了数据链路层的 MTU 限制时,必须执行分片操作。这一过程涉及将超长的 IP 数据报拆分为多个较小的片段,每个片段独立地在网络中传输。尽管这些分片在网络中的传输路径可能不同,但它们最终都会到达目的主机。在目的主机的网络层,这些分片将被重新组装,恢复成原始的 IP 数据报,确保数据的完整性和正确性。
TCP 的分段处理
对于 TCP(传输控制协议),当应用层数据过长时,TCP 协议会在组装 TCP 报文段时根据需要进行数据拆分。这意味着 TCP 会在数据过大之前,主动将其分割成多个较小的 TCP 报文段。每个 TCP 报文段都有自己的头部信息,包括序列号等,以确保数据的可靠传输。
UDP 的数据拆分
与 TCP 不同,UDP(用户数据报协议)不提供分段、重传、确认或连接管理等特性。当使用 UDP 发送数据,且数据长度超过 MTU 时,数据的拆分发生在 IP 层。IP 层将 UDP 数据报作为有效载荷进行分片,每个分片都包含必要的信息以在目的主机进行重组。
分片丢失或损坏的处理
如果任何分片在传输过程中丢失或损坏,目标主机将无法正确重组原始数据包。在这种情况下,除非应用层有特定的恢复机制(通常 UDP 应用层没有这样的机制),否则整个数据包将被丢弃。
这种处理机制的差异体现了 TCP 和 UDP 在设计上的根本区别,也决定了它们在不同应用场景下的适用性。TCP 的可靠性使其适合需要确保数据完整性的应用,而 UDP 的低延迟特性则适用于对实时性要求较高的场景。
# 路由器 & 路由表 & 路由转发
路由器的功能 :路由器是网络中的关键设备,负责在不同网络之间转发数据包。它们的主要功能包括路径选择和数据包转发。
路由表的作用 :路由器维护一个路由表,该表包含了指向特定网络地址的路径信息。路由表是路由器进行路径选择的关键工具。
路由转发过程 :当路由器收到一个数据包时,它会检查数据包的目的 IP 地址,并根据路由表中的信息,选择一个最合适的路径。路由器将数据包转发给下一个路由器或最终目的主机。这种逐跳的传输方式被称为 “多跳” 传输。
逐跳通信 :在逐跳通信中,每个路由器只能决定数据包的下一跳位置,而无法直接与最终目的地建立连接。路由器的任务是为每个经过的数据包找到一个合适的下一跳路由器。
路由过程 :路由是指在网络中寻找从源头到目的地之间的合适路径的过程。这个过程涉及到路由器之间的信息交换和路由表的更新,以确保数据包能够沿着最佳路径传输。
路由器作为中间结点 :路由器可以作为端到端通信系统中的一个中间结点,负责将数据包从一个网络转发到另一个网络。在某些情况下,主机也可以支持路由功能,尤其是在边缘网络中。
# NAT
NAT(网络地址转换)技术是一种在不同网络间转换网络地址的网络层技术。它在路由器上特别常见,用于将局域网内的私有 IP 地址转换为公有 IP 地址,以便访问互联网。
IPv4 地址空间的限制
由于 IPv4 地址空间有限,并且在全球范围内已经接近枯竭,NAT 技术允许多个设备共享单个公有 IP 地址,从而有效地延长了可用的 IPv4 地址。
安全性
NAT 路由器在数据包从局域网发送到互联网时,会修改数据包的源 IP 地址,将其从私有 IP 地址更改为路由器的公有 IP 地址,这为局域网内的设备提供了一定程度的匿名性和安全性。
端口地址转换(PAT)
由于多个设备可能共享同一个公有 IP 地址,NAT 还会执行端口地址转换(PAT),为每个设备分配不同的端口号,以唯一标识它们。这意味着传输层的源端口和网络层的源 IP 地址都会被修改。
NAT 的转发表
NAT 设备会维护一个转发表,记录内部设备的私有 IP 地址和端口号与相应的公有 IP 地址和端口号的映射关系。这使得当数据包返回时,NAT 设备能够将它们正确地路由回到发送设备。
# DHCP
DHCP(动态主机配置协议)是一种在网络中自动分配 IP 地址给主机的应用层协议。它基于 UDP 传输,使得新加入网络的设备能够获得必要的网络配置信息,如 IP 地址、子网掩码、默认网关等。
当一个主机连接到网络时,它会发送一个 DHCP 广播报文,询问网络中的 DHCP 服务器。所有网络上的设备都能接收到这个广播,但只有配置为 DHCP 服务器的设备能够响应这个请求。在家庭或小型办公网络中,通常由路由器充当 DHCP 服务器的角色。
DHCP 服务器在接收到请求后,会检查自己的地址池和记录,决定是分配一个新的 IP 地址还是续租之前分配的 IP 地址。如果服务器找到了主机的记录,它会根据记录中的信息分配 IP 地址;如果没有找到,它会从地址池中选择一个可用的 IP 地址进行分配。
DHCP 分配的 IP 地址通常是临时的,具有一个租约期限。租约期满后,主机需要与 DHCP 服务器通信以续租或获取新的 IP 地址。这个过程确保了 IP 地址的动态分配和有效管理。
# ICMP
ICMP(Internet Control Message Protocol,互联网控制消息协议)是一种网络层的协议,用于提供 IP 协议的诊断和控制信息。ICMP 报文用于传递网络通信过程中的错误信息和其他网络状态信息,帮助源主机或网络管理员了解数据传输过程中的问题。
ICMP 报文封装在 IP 数据报中,因此它依赖于 IP 协议进行传输。虽然 ICMP 通常被认为是网络层的一部分,但它的功能跨越了网络层和传输层。
ICMP 广泛应用于多种网络诊断工具中,例如:
- Ping:使用 ICMP 请求和回答报文来测试主机之间的连通性。
- Traceroute(在 Windows 中为 tracert):利用 ICMP 报文来追踪数据包在网络中的传输路径。
# 以太网
TCP/IP 协议集专注于定义网络层和传输层的功能,以便实现端到端的数据传输和路由。它依赖于其他标准来处理数据链路层和物理层,这些层级的实现细节通常由如以太网、Wi-Fi 等技术所规范。尽管 TCP/IP 协议集并未全面定义这些底层,但它为构建更高层的网络通信提供了坚实的基础。
对于物理层和数据链路层的研究,我们需参考 IEEE 802.3 标准,即以太网标准。此标准涵盖了局域网中的数据传输细节,包括数据链路层的帧结构和物理层的规范,如传输介质、电缆规格、数据传输速度以及设备的连接方法。
# 交换机
早期的以太网结构是基于共享介质的,这意味着多个主机共享同一个网络介质来传输数据。在这种环境下,如果多个主机尝试同时发送数据,就会发生数据碰撞,导致传输失败。为了避免这种情况,需要采用特定的算法,如 CSMA/CD(Carrier Sense Multiple Access with Collision Detection,载波侦听多路访问 / 碰撞检测),来管理主机对共享介质的访问。
随着网络技术的发展,共享以太网逐渐被星形拓扑结构的网络所取代。在星形拓扑中,每个主机通过一条独立的网线与交换机相连,交换机负责为每个主机提供全双工通信,从而避免了数据碰撞的问题。
网桥和交换机是工作在数据链路层的网络设备,它们能够连接多个链路层网络,构成一个扩展的局域网。交换机拥有自己的 MAC 地址,并通过多个接口与网络中的设备相连。通过一段时间的 “学习”,交换机可以构建一个端口地址表,该表存储了 MAC 地址与接口编号的对应关系,使得交换机能够智能地将数据帧转发到正确的接口。
交换机的使用有效地扩展了网络的范围,隔离了冲突域,并提升了数据传输速度。通过这种方式,交换机优化了网络的性能,提高了网络的可靠性和效率。
# 以太网帧
当应用层数据向下传递至网络层时,该数据将被封装成网络层的协议数据单元,例如 IP 数据报。随后,这些数据在传递至数据链路层时,会被进一步封装成数据链路层的协议数据单元,即以太网帧。以太网帧是数据链路层的构建块,它不仅包括来自上层的数据有效载荷,还包含必要的以太网头部和尾部信息,这些信息用于确保数据在局域网内的可靠传输。
# ARP 协议
在网络传输过程中,我们依赖 IP 地址来确定目标主机的位置。然而,IP 地址可能发生变化,而 MAC 地址作为链路层地址,通常由设备制造商分配,具有唯一性和固定性。在构建以太网帧时,我们需要知道目的 IP 地址对应的 MAC 地址。如果只知道目的 IP 地址,就需要通过地址解析协议(ARP)来获取 MAC 地址。
ARP 协议负责将 IP 地址映射到 MAC 地址。以下是对您提供的 ARP 协议描述的改写和详细解释:
ARP 协议的作用
ARP 协议允许网络设备通过 IP 地址查询对应的 MAC 地址。这是实现 IP 层到数据链路层地址转换的关键步骤。
ARP 请求过程
- 主机 A 首先检查自己的 ARP 缓存,看是否已经有了目的 IP 地址对应的 MAC 地址。如果有,直接使用该 MAC 地址构建以太网帧。
- 如果 ARP 缓存中没有找到对应的 MAC 地址,主机 A 会在本地网络上发送一个 ARP 广播请求。这个广播请求的目的 MAC 地址设置为全 1(FF-FF-FF-FF-FF-FF),意味着同一网络内的所有设备都能接收到这个请求。
- 网络上的所有主机收到 ARP 广播后,会检查广播中的 IP 地址是否与自己的 IP 地址匹配。只有 IP 地址匹配的主机 B 会响应 ARP 请求,将自己的 MAC 地址和 IP 地址发送给主机 A。
- 主机 A 接收到主机 B 的响应后,将 B 的 MAC 地址和 IP 地址存入自己的 ARP 缓存,然后使用这个 MAC 地址构建以太网帧,发送原本的数据。
ARP 缓存
ARP 缓存是一个临时存储 IP 地址和 MAC 地址映射的表,用于加速地址解析过程。缓存中的条目通常具有时效性,过期后需要重新进行 ARP 请求。
# 网络回环设备
网络回环设备是一种操作系统提供的虚拟网络接口,它允许同一主机上的不同进程或应用程序通过网络协议栈进行通信。这种设备通过内核协议栈的传输层和网络层处理数据,但避免了数据在物理层的传输,从而不会经过网卡等网络硬件。
环回通信的一个显著特点是它不受 MTU 大小的限制,这使得在主机内部传输较大的数据包时,不会因为 MTU 限制而导致分片。环回设备通常关联有一个特殊的回环 IP 地址,如 IPv4 的 127.0.0.1 或 IPv6 的:: 1,这些地址专门用于标识主机自身的网络接口,确保数据在主机内部正确路由。
# 网卡
网卡是计算机硬件的关键组成部分,它负责将主机连接到网络并处理数据的发送与接收。操作系统在准备好以太网帧后,会将这些帧传递给网卡,网卡随后将数字信号转换为电信号,通过物理媒介如网线进行传输。
在这个过程中,直接内存访问(DMA)技术发挥着核心作用。DMA 技术使得网卡能够直接从系统内存读取数据,无需 CPU 的介入,从而大大提高了数据传输的效率并减少了 CPU 的工作负载。
网卡与操作系统的紧密协作确保了数据封装和发送过程的顺利进行。操作系统生成数据帧,而网卡则负责将这些帧转换为适合网络传输的信号,并通过物理连接发送到目的地。