1. Principles of network applications
创建一个网络应用
创建一个网络应用的核心，是编写一个分布式程序，使其可以运行在不同的端系统上，并能通过网络相互通信。（例如，web服务器软件与浏览器软件）
应用程序只运行在终端上（只在端系统上开发应用），应用程序员不需要为网络核心设备编写程序，我们默认可以调用一些API，这极大地方便了网络应用的开发和快速部署。
我们不需要为网络核心设备编写程序的原因：一方面会浪费大量的时间与精力，另一方面网络的核心设备我们是接触不到的。
1.1 网络应用架构
在开发一个应用程序之前，首先要决定采用什么样的网络应用架构，网络应用架构规定了在各个端系统上组织应用程序的方法，目前有两种主流的网络应用架构：
- 客户-服务器架构（Client-server） 中心化的架构
- 对等架构（Peer-to-Peer ，P2P） 没有服务器的概念
1.1.1 客户-服务器架构
服务器（server）：
- 有一台总是在线的主机，上面运行着服务器程序 （server） （有请求要及时响应请求）。
- 服务器主机 （server machine） 具有永久的、众所周知的地址。
- 服务器端会在很多地方部署大量的计算集群，且具有高速网络。
客户（client）：
- 用户终端上运行一个客户程序 （client），需要时与服务器程序通信，请求服务。
- 客户机（client machine）使用动态地址，通常不会总是在线。
客户只与服务器通信，客户之间不通信。
1.1.2 P2P架构
- 没有总是在线的服务器主机。
- 任意一对端系统（对等方）可以直接通信。
- 对等方多为用户自己的计算机，使用动态地址。
- 每个对等方既可请求服务，也可提供服务。
- 典型的P2P应用：BT、迅雷、Skype（将P2P架构与Client-Server架构结合）、PPLive。
客户服务器的架构的性能瓶颈在服务器端，服务器的性能决定了整个应用的访问数量与速度，在 P2P 中并没有这种瓶颈，但 P2P 架构管理起来较为困难，因为对等方的 IP 是不断变化的，资源发现较为困难。
1.1.3 两种架构的比较
| 客户-服务器架构 | P2P架构 | ||
|---|---|---|---|
| 资源集中： | 资源（服务）只在某些固定的终端上提供 | 资源分散： | 任何终端都可以提供资源（服务） |
| 优点： | 资源发现简单 | 优点： | 易于扩容、均衡网络流量 |
| 缺点： | 集中式计算带来的问题，如服务端扩容压力、网络流量不均衡、响应延迟长 | 缺点： | 资源发现困难，社会问题（版权、安全性等） |
1.2 不同终端上的进程通信
进程： 主机上运行的程序。
在分布式应用中，不同终端上的进程需要通信，通信的方法主要有：
在同一台主机中，由操作系统来提供进程之间的通信。在不同的主机上，通过交换报文进行通信。在一次确定的通信会话中，总能标示一方为客户进程，另一方为服务器进程（包括P2P架构）：
- 客户进程：主动发起请求的进程。
- 服务器进程：接收请求的进程。
套接字（socket）：进程与网络的接口（应用程序和网络之间的一扇门）。
- 发送报文：发送进程将报文推到门外。
- 门外的运输设施（因特网）将报文送到接收进程的门口。
- 接收报文：接收进程打开门，即可收到报文。
套接字是应用层和传输层的接口，也是应用程序和网络之间的API。
每个进程需要一个标识，以便其它进程能够找到它，那么进程如何该如何标识自己？可以用进程所在主机的地址来标识进程吗？
答案是不能，因为同一个主机上可能运行着许多进程，我们用端口号来区分同一个主机上的不同进程
进程标识包括：
- 主机地址。
- 与该进程关联的端口号。
端口号的例子：HTTP server使用端口 80，Mail server使用端口 25。
1.3 应用需要什么样的传输服务
在创建一个应用程序时，开发者需要选定一种传输服务。
-
Data integrity（数据完整性）
- 有些应用（如音视频）可以容忍一定程度的数据丢失。
- 有些应用（如加密的文件）要求完全可靠的数据传输。
-
Timing（时效性）
- 有些应用（如网络电话，交互式网络游戏）要求延迟保证。
- 有些应用（如邮件传输）对延迟不敏感。
-
Throughput（吞吐量）
- 有些应用（如多媒体）要求保证最低可用带宽。
- 有些应用（称弹性应用，微信文字信息）可以适应各种可能的带宽。
-
Security（安全性）
- 加密，数据完整性，……
1.4 因特网能够提供的传输服务
因特网提供2种传输服务，分别用TCP和UDP协议实现。
-
TCP service:
- 面向连接：保证传输顺序。
- 可靠传输：不出错。
- 流量控制：发送进程不会 ‘‘压垮’’ 接收进程。
- 拥塞控制： 网络超载时抑制发送进程。
- 不提供：及时性，最低带宽保证，安全性。
-
UDP service:
- 通过因特网接收和发送报文。
- 不提供：顺序保证，可靠传输，流量控制，拥塞控制，及时性，最低带宽保证，安全性。
- 相对于TCP延迟相对小一点，但可能会丢包。
1.5 应用层协议
应用进程之间交换的报文是什么样的？
- 应用层协议定义：
- 报文类型：request，response
- 报文语法：报文中的字段及其描述。
- 报文语义：各字段中信息的含义。
- 发送/响应报文应遵循的规则。
- 公共域协议:
- 在RFC文档中定义。
- 允许互操作。
- e.g.， HTTP, SMTP
- 专用协议:
- e.g.， Skype
1.6 小结
- 为创建一个新的网络应用，需要：
- 选择一种网络应用架构：客户 - 服务器 or P2P
- 选择一种网络服务：TCP or UDP
- 确定一个端口号（主机进程的唯一标识）
- 定义应用层协议（可以用已有的协议，如HTTP、SMTP…）
- 编写客户程序和服务器程序（调用套接字接口）
- 网络应用和应用层协议：
- 应用层协议只是网络应用的一部分
- 网络应用还包括客户程序、服务器程序等
- 要求掌握的概念：
- 客户-服务器模型
- 网络应用编程接口
2. Web and HTTP
Web应用画像
- 应用层资源：网页（web pages）
- 网络应用架构：客户-服务器架构
- 客户：浏览器
- 服务器：web服务器
- 要求的网络服务：TCP服务
- 端口号：80
- 应用层协议：HTTP（Hyper Text Transfer Protocol）HTTPS(在安全性能上做了优化)
一些术语
- Web page由一些对象（object）组成。
- 对象简单来说就是文件，可以是HTML文件、图像、Java小程序、音频文件，…
- 每个对象通过一个URL (Uniform Resource Locator) 获取，例如：
- HTML（Hyper Text Markup Language）是一种格式语言，用于描述页的内容和显示方式。
- HTML文件是用HTML语言编写的超文本文件，需要通过专门的浏览器软件进行展示。
- Web页通常包含一个HTML基本文件和若干引用对象，每个引用对象在文档中用其URL给出。
- 超文本文件：包含超链接的文件，超链接中的文字包含有连接到文档中其他位置或者其它文档的链接，允许从当前阅读位置直接切换到超链接所指向的位置。
- 超文本（Hyper text）：一种信息组织方式，通过超链接将各种不同空间的文字信息组织成网状文本。
2.1 超文本传输协议–HTTP 概述
Web采用客户-服务器模式：
- client: 浏览器请求、接收和显示web对象。
- server: Web服务器应客户请求发送对象。
HTTP协议：定义了浏览器和web服务器之间的通信规则。
HTTP的主要版本：HTTP 1.0（RFC 1945）和 HTTP 1.1（RFC 2068）
HTTP为什么要使用TCP服务：Web服务器并不保留客户所请求的信息，HTTP协议是无状态的，为了发送文件的稳定。
HTTP使用TCP服务过程：
- 客户发起到服务器 80 端口的 TCP 连接（客户端创建一个套接字）
- 服务器接受（服务器端监听80端口）来自客户的TCP连接（服务器端创建一个套接字）
- 浏览器和服务器交换HTTP报文 （通过各自的套接字）
- 关闭TCP 连接（关闭各自的套接字）
2.2 非持久连接和持久连接
主要区别：在一个TCP连接上只能传输一个对象还是能传输多个对象。
2.2.1 非持久 HTTP
- 在一个TCP连接上最多发送一个对象。
- HTTP/1.0 使用非持久连接。
内容获取过程：
假设用户输入以下URL：http://www.someSchool.edu/someDepartment/home.index (包含文本及10个Jpeg图像)
- HTTP客户发起到以下HTTP 服务器进程的连接 www.someSchool.edu on port 80。
- www.someSchool.edu上的HTTP服务器在端口80等待TCP连接，接受连接，并通知客户。(建立连接)
- HTTP客户将一个HTTP请求报文（包含URL）写入它的套接字，报文指示希望获取以下对象：someDepartment/home.index
- HTTP服务器接收请求报文，构造包含所请求对象的响应报文，将报文写入它的套接字中。(请求对象)
- HTTP 服务器关闭TCP连接。(关闭连接)
- HTTP 客户接收包含HTML文件的响应报文，显示HTML文件，解析文件发现有10个引用的jpeg对象。
- 对于每个jpeg对象，重复步骤 1-6（进行十次）。
非持久HTTP的响应时间：
RTT (Round-Trip Time)：一个小分组从客户发送到服务器，再返回客户的时间。
相应的时间主要包括：
- 建立TCP连接用时一个RTT。
- 发送HTTP请求至收到响应的前几个字节用时一个RTT。
- 传输文件的时间。
请求一个对象用时2RTT（忽略对象传输时间），则上面题目中请求一个完整的网页用时22RTT（11个对象）
非持久HTTP 的问题：
获取每个对象需要一次TCP连接，每个TCP连接需要消耗操作系统资源，浏览器需要打开多个TCP连接来获取一个网页。
2.2.2 持久 HTTP
- 在一个TCP连接上可以发送多个对象。
- HTTP/1.1 缺省使用持久连接。
- 服务器在发送响应后保持连接。
- 同一对客户 - 服务器之间的后续HTTP报文可以在该连接上传输。
持久HTTP又分为：
- 无流水线方式：客户仅当收到前一个响应后再发送新的请求（串行）。
- 流水线方式：客户每解析到一个引用对象就可以发送请求，可在一个RTT时间内请求所有引用对象。
针对上面的问题：
- 无流水线方式：需要花费12个RTT（一次TCP连接、显示HTML文件的请求、10个文件的10次请求）。
- 流水线方式：只需花费3个RTT（一次TCP连接、显示HTML文件的请求、10个文件的1次请求）。
2.3 HTTP 报文格式
- 请求报文：客户发往服务器
- 响应报文：服务器发往客户
HTTP报文由ASCII文本构成。
HTTP请求报文：
HTTP请求报文：
报头包括：
上传表单输入：
- Post 方法
- Web页通常包含表单输入。
- 输入的表单内容放在报文体中上传到服务器。
- URL 方法
- 使用 GET 方法。
- 输入内容放在请求行的URL字段中上传，如：www.somesite.com/animalsearch?monkeys&banana。
HTTP方法：
HTTP 响应报文：
HTTP 响应状态代码：
2.4 用户与服务器交互: cookie
四个组成部分：
- HTTP响应报文中的cookie首部行。
- HTTP请求报文中的cookie 首部行。
- 保存在用户主机的cookie文件，由用户的浏览器管理。
- Web网站的后端数据库。
例子：Susan第一次访问某个电子商务网站，当HTTP请求报文到达该网站时，网站为其创建:
- 一个ID
- 在后端数据库中为该ID建立一个表项。
Cookies: 保存"状态"：
Cookies交互的两种方式：
- 服务端：信息保存在服务端的后端数据库，返回ID给客户。
- 客户端：信息发回客户端，保存在cookie文件中，并随请求报文发送给服务器。
2.5 Web缓存（代理服务器）
代理服务器: 代表原始服务器满足HTTP请求的网络实体，保存最近请求过的对象的拷贝。
用户要设置浏览器：所有HTTP请求首先发往web缓存。
浏览器将HTTP请求发送给web缓存：
- 对象在web缓存中: web缓存返回对象。
- 对象不在web缓存中：web缓存从原始服务器获取对象，缓存在本地，然后返回给客户。
Q：web缓存如何知道对象的原始服务器？
A： HTTP请求头中的 host 首部行指出了原始服务器
Web cache既是服务器又是客户：
- 对于浏览器来说是服务器。
- 对于原始服务器来说是客户。
Web cache通常由ISP提供，多级ISP可能形成多级web缓存。
Web caching 的作用：
- 减少客户请求的响应时间。
- 减少机构接入链路上的流量。
Cache Example：
原始：
链路升级：
安装Web Cache：
2.6 条件 GET
代理服务器如何发现缓存的对象是不是最新的？
2.7 小结
- 因特网上的每个资源（对象）都可以通过URL访问
- HTTP使用TCP连接
- 非持续HTTP
- 持续HTTP
- 客户与服务器交互：
- 报文请求/响应
- HTTP服务器是无状态的，利用cookie技术可以保存用户状态
- 使用web缓存提高请求-响应速度：
- 使用条件get获得最新的对象副本
3. File Transfer and FTP
3.1 文件传输应用画像
- 应用层资源：文件
- 网络应用架构：客户 - 服务器
- 使用传输服务：TCP
- 端口号：21、20
- 应用层协议：FTP
- 使用命令/响应交互（不是像HTTP那样使用报文交互）
- 通常情况下，用户通过FTP用户代理与文件服务器交互
3.2 FTP用户代理
3.3 使用分离的控制连接和数据连接
- 控制连接：
- 使用端口21，传送客户命令和服务器响应。
- 控制连接在整个会话期间一直保持。
- 数据连接：
- 使用端口20，传输文件。
- 每个数据连接只传输一个文件，发送方用关闭连接表示一个文件传输结束。
3.4 建立连接
-
服务器在端口21等待客户。
-
客户使用临时端口号建立连接。
-
客户选择一个临时端口号，在该端口上等待服务器的连接请求。
-
客户在控制连接上用PORT命令将临时端口号发送给服务器。
-
服务器使用端口20与客户机给出的端口建立连接。
3.5 有关控制连接与数据连接的问题
Q：为什么将控制连接与数据连接分开？
A：不会混淆数据与命令/响应，简化协议设计和实现；在传输文件的过程中可以继续执行其它的操作；便于控制传输过程（如客户可以随时终止传输）文章来源：https://www.toymoban.com/news/detail-717423.html
Q：为什么用关闭数据连接的方式结束文件传输？
A：允许动态创建文件（不需预先告知文件的大小）文章来源地址https://www.toymoban.com/news/detail-717423.html
3.6 FTP小结
- 使用TCP协议，服务器端口号21、20
- 采用命令/响应交互方式
- 使用两条TCP连接：
- 控制连接（端口21）：会话期间始终保持。
- 数据连接（端口20）：每条连接仅传输一个文件，且客户与服务器角色交换。
到了这里，关于【计算机网络-自顶向下方法】应用层（HTTP、FTP）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
