《计算机网络自顶向下》学习随记第二章：应用层（1）

最新推荐文章于 2026-06-17 22:13:19 发布

原创最新推荐文章于 2026-06-17 22:13:19 发布 · 854 阅读

21 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#计算机网络 #学习

计算机网络专栏收录该内容

7 篇文章

订阅专栏

第二章应用层

文章目录

1 应用层协议原理
2 Web and HTTP
总结

1 应用层协议原理

1.1 网络应用程序的体系架构

CS架构（客户-服务器架构）

客户之间不直接通信，服务器具有固定的、周知的地址（IP地址）
需配备大量的数据中心

P2P架构

应用程序在间断连接的主机对之间使用直接通信
自扩展性：成本有效（？），不需要庞大的服务器基础设施和服务器带宽。

1.2 进程通信（process）

多个端的系统上的程序其实是通过进程通信实现的，而不是程序。
发送进程生成并向网络上发送报文，接收进程接受这些报文。
进程通过套接字socket这一软件接口向网络发送报文和从网络上接收报文。
在这里插入图片描述
一台主机上运行着很多进程，如何辨别呢——端口号，来实现进程寻址。

1.3 套接字之间如何传送？

这就涉及到了运输层协议，这里就拿快递公司来打比方吧，方便理解！
那运输层的协议需要考虑哪些方面呢【我寄快递的话，都要考虑哪些因素】？

可靠数据传输：确保数据正确、完全地交付 or 可以接受一定量地数据丢失【相当于要不要选顺丰】
吞吐量：发送进程能够向接收进程交付比特的速率，就要考虑你的应用是否对带宽有要求【能不能寄大件】
定时：时延，玩家的响应时间【快递几天能送达】

下面就是两种典型的运输层协议了：

TCP

面向连接：应用层数据流动之前，客户端和服务器需要互换运输层的控制信息（对暗号），并且建立的连接是全双工的，结束后也必须拆除连接。
可靠的数据传送服务：将相同的字节流交付，没有字节的丢失和冗余。
拥塞控制：当网络出现拥塞时，会抑制发送进程。

UDP

无连接：不需要提前握手，只提供最小服务
无拥塞控制

【拓展】
TCP和UDP都不提供任何加密服务，也就是以明文口令传送的，可能在中间链路被嗅探和发现。因此，出现了SSL（Secure Socket Layer）——TCP的加强版。

流行的应用层协议和对应的传输层协议

在这里插入图片描述

2 Web and HTTP

2.1 overview

一个web页面是由对象（object）组成的，这里的对象包括图片、视频文件、小程序等等，HTML基本文件通过URL来引用页面里的对象，下面是URL的构成，包括主机名和路径
在这里插入图片描述
HTTP采用TCP作为支撑运输协议，由于TCP是可靠的，这意味着，客户进程发出的每一个请求最终都能完整地到达服务器，服务器进程发乎地每个HTTP响应报文都能完整地到达客户。
HTTP还是一个无状态协议（stateless），因为HTTP服务器不保存任何关于客户的信息，也就是说每个客户对于服务器来说都是陌生人，加入某个客户在很短时间内两次请求同一个对象，服务器第二次也会接着发，不会刚发过就不发给你了。

2.2 非持续连接/持续连接

非持续连接（Non-persistent HTTP）

在非持续连接模式下，每个HTTP请求/响应对都通过一个新的TCP连接进行。这意味着：

对于每个请求，客户端都需要与服务器建立一个新的TCP连接。
数据传输完成后，连接会被立即关闭。
下载多个对象需要多个连接，因为每个对象的请求都需要单独的连接。

例如，如果用户请求一个网页，该网页包含多个对象（如HTML文件、JPEG图像、Java小程序、音频文件等），则每个对象的请求都需要建立一个新的TCP连接，传输完成后关闭连接。这种方式的缺点是增加了额外的连接建立和断开的开销，特别是在下载包含多个对象的网页时。

持续连接（Persistent HTTP）

持续连接模式允许多个请求和响应通过同一个TCP连接进行，这样可以显著提高性能，特别是在以下方面：

减少延迟：因为避免了为每个请求建立和关闭连接的开销。
减少网络负载：减少了创建和销毁连接的频率，从而降低了网络负载。
提高效率：特别适用于需要请求多个对象的场景，如加载一个包含多个资源（如图片、脚本、样式表）的网页。

2.3 HTTP报文

HTTP请求报文

请求报文由三部分组成：请求行（Request Line）、请求头（Headers）、请求体（Body）。

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

在这里插入图片描述

请求行：包含三个字段——方法（Method）、请求的资源的URL（URL）、HTTP版本（HTTP Version）。例如：GET /index.html HTTP/1.1。
- Method:
  - GET 、POST、HEAD、PUT、DELETE
请求头：包含若干行，每行由一个字段名和一个字段值组成，字段名和字段值之间用冒号（:）分隔。请求头提供了关于请求的附加信息，如客户端信息、接受的内容类型、内容编码等。请求头的结尾是一个空行，表示请求头结束。
请求体：可选部分，用于包含发送给服务器的数据。例如，当使用POST方法提交表单数据时，表单数据就在请求体中。对于GET方法，通常不包含请求体。

HTTP响应报文（Response Message）

HTTP/1.1 200 OK
Date: Mon, 10 Feb 2025 09:18:455 GMT
Server: Apache/2.4.6 (CentOS)
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT
ETag: "17dc6-a5c-bf716880"
Accept-Ranges: bytes
Content-Length: 2652
Keep-Alive: timeout=10, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1

<html>
<head>
<title>Sample Page</title>
</head>
<body>
<h1>Welcome to the sample page</h1>
</body>
</html>

响应报文也由三部分组成：状态行（Status Line）、响应头（Headers）、响应体（Body）。

状态行：包含三个字段——HTTP版本（HTTP Version）、状态码（Status Code）、状态消息（Status Message）。例如：HTTP/1.1 200 OK。
响应头：类似于请求头。
响应体：包含服务器返回给客户端的数据。对于状态码200 OK，响应体通常包含请求的资源内容。对于状态码如301 Moved Permanently，响应体可能包含新的位置信息。

2.4 用户和服务器之间的交互——cookie

前面说http是无状态的，但我们希望能够识别用户，于是，出现了cookie，允许站点对用户进行跟踪。
当用户首次访问一个网站时，网站可以发送一个或多个Cookie到用户的浏览器。浏览器将这些Cookie存储在本地，并在随后的请求中发送回服务器。服务器可以根据这些Cookie来识别用户，并据此提供个性化的服务。