生气！极其不友好的考纲

应用层协议的原理

网络应用体系结构

规定如何在各种端系统上组织应用程序，由研发者设计,规定了如何在各种端系统上组织该应用程序。
e.g.

  1. CS体系结构(Client-Server architecture)
  2. P2P体系结构(P2P architecture)

进程通信

进程通信实际上是进程(Process)而不是程序，多个进程运行于相同的端系统上时，它们利用进程间通信机制相互通信；进程运行于不同的端系统上时，通过跨越计算机网络交换报文(Message)而互相通信。
进程与计算机网络之间的接口是套接字(Socket)，其中一部分套接字建立了网络应用程序的可编程接口，被称之为应用程序与网络之间的应用程序编程接口(API, Application Programming Interface)。
此处值得一提的是进程寻址需要IP与端口号。地址与门牌号

可供应用程序使用的运输服务

以下为分类

  1. 可靠数据传输
  2. 吞吐量
  3. 定时 其实是延迟
  4. 安全性

因特网提供的运输服务

  1. TCP
  2. UDP
应用 应用层协议 支持的运输协议
电子邮件 SMTP TCP
远程终端访问 Telnet TCP
Web HTTP TCP
文件传输 FTP TCP
流式多媒体 HTTP TCP
因特网电话 SIP、RTP TCP/UDP

应用层协议的实现过程

应用层协议定义了运行在不同端系统上的应用程序如何进行报文传递，特别定义了一下几部分：

  1. 交换的报文类型
  2. 各种报文类型的语法
  3. 字段的语义
  4. 确定一个进程何时以及如何发送报文，对报文进行响应的规则

Web 应用和 HTTP 协议

终于到我会一点点的地方了
Web的应用层协议核心就是HTTP(HyperText Transfer Protocol)协议，HTTP协议是一个无状态协议。

持续连接与非持续连接

每个请求/响应都是由单独的一个TCP连接发送的，是为非持续性连接，反之则是持续连接。
非持续连接存在以下缺点：

  1. 必须为每个请求的对象建立和维护一个全新的连接。
  2. 每个对象经受两倍RTT(Round-Trip Time)的交付延迟，即一个RTT用于创建TCP，一个RTT用于请求和接收一个对象。

报文格式

请打开F12
Chrome似乎看不到raw的，打开fiddler
众所周知，百度是用来测试网络连通性的
以下报文删去了一部分内容
请注意HTTPS类型的traffic请在fiddler中信任根证书
请求报文样例

1
2
3
4
5
6
7
8
9
10
11
12
GET https://www.baidu.com/ HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Accept: text/plain, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
X-Requested-With: XMLHttpRequest
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://www.baidu.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7

响应报文样例

1
2
3
4
5
6
7
8
9
10
HTTP/1.1 200 OK
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Mon, 12 Oct 2020 08:05:44 GMT
Expires: Mon, 12 Oct 2020 08:05:44 GMT
Server: BWS/1.0
Vary: Accept-Encoding
Content-Length: 49

没什么好讲的（确信
来记一些状态码吧！

  • 200 OK
  • 301 Moved Permanently
  • 400 Bad Request
  • 404 Not Found
  • 505 HTTP Version Not Supported
  • 500 Internal Server Error

前文已经提到了，HTTP是一种无状态协议，这意味着将无法识别用户，为了解决这个问题，HTTP使用了Cookie对用户进行识别追踪。
Using Cookie

Web缓存器

Web Cache A.K.A Proxy Server
How does it work:

  1. 浏览器创建一个到Web缓存器的TCP连接，并为向其中所请求的对象发送一个HTTP请求
  2. Web缓存器检查其本地是否存有该对象，若有则响应报文并返回该对象
  3. 若不存在该对象，则在与服务器(该对象本来的来源处)的TCP连接上，发送对此对象的请求。
  4. 当Web缓存器接收到此对象时，先于本地存储一份副本，随后将其发至客户端。

Why: 代替原始服务器满足HTTP请求 并且减少接入公共因特网带宽成本
e.g. CDN(Content Distribution Network)

条件GET方法

Client请求：If-modified-since: <date>
未修改则：HTTP/1.0 304 Not Modified
修改则：<data>

FTP 协议的实现机制

书上没有这一节
参阅以前的课件作如下描述
FTP用于传输文件到远程主机/从远程主机下载文件，存在以下两种模式
client/server模式

  • client: 发起传输的一方
  • server: 远程主机

对于ftp服务器，其默认端口号为21(控制端口)。

FTP传输过程

  1. FTP客户首先发起建立1个与FTP服务器端口21之间的TCP控制连接, TCP为传输层协议
  2. 客户在控制连接上获得身份认证，发送各种控制命令.
  3. 服务器收到1个文件传输命令时, 服务器在端口20(数据传输端口)创建1个与客户端口的TCP数据连接（Port）
  4. 1个文件传输后,服务器结束这个TCP数据连接.

其他？（我也不知道怎么描述

  1. 服务器创建第2个TCP与客户的数据连接来传输下一个文件.
  2. 控制连接: 带外发送控制信息
  3. FTP 服务器维护用户状态信息: 当前目录, 先前身份认证

PORT模式

PORT模式下的FTP服务： 缺省情况下PORT模式的数据端口是20， 控制端口是21（控制端口可以设定， 本文假定使用21）。 当进行连接时,客户端使用一个随机的端口N（N大于1024)连接服务器的控制端口21， 然后客户端开始监听端口N+1，并向服务器发送命令 PORT N+1，服务器用自己的数据端口20连回客户的N+1端口。 由于PORT模式仅仅是发送端口给服务器，由服务器连回客户端，如果客户端有防火墙，这样的连接会被认为是外部主机试图连接内部的主机， 通常情况下是不允许的。

PASV模式

PASV模式下的FTP服务： 当进行连接时,客户端使用一个随机的端口N（N大于1024) 连接服务器的控制端口21， 并向服务器发送命令 PASV，服务器使用一个随机的数据端口M(M>1024)并发回客户端, 客户端用数据端口N+1连接服务器的端口M。 由于客户端发起数据连接， 这样就解决了防火墙带来的问题。

DNS 的功能和实现方法

功能

  1. 主机名到IP地址转换 (Main)
  2. 主机别名
  3. 邮件服务器别名(MX记录)
  4. 负载均衡

实现

存在的问题

  1. 单点故障
  2. 通信容量
  3. 远距离的集中式数据库
  4. 维护

解决方案 —— 分布式、层次数据库

层次结构

DNS Architecture
由根DNS服务器提供TLD(Top-Level Domain)服务器的IP地址，每个TLD服务器又提供了权威DNS服务器的IP地址，最后由权威DNS服务器，将这些主机名映射为IP地址。

DNS缓存

其实是本地DNS服务器，可参见Web Cache做类比。

DNS记录和报文

DNS记录由四元组构成，如下

1
（Name, Value, Type, TTL)

其中TTL代表该记录的生存时间，Type决定了Name和Value。
以下是几种常见的Type与其对应的Name和Value：

  • (Name, IPv4 Address, A, TTL) e.g. (blog, IPv4 Address, A, TTL)
  • (Name, IPv6 Address, AAA, TTL) e.g. (blog, IPv6 Address, AAA, TTL)
  • (Name, Domain, NS, TTL) e.g. (Tinysnow, A NS Server, NS, TTL)
  • (Name, Domain, CNAME, TTL) e.g. (blog, skadiwo.github.io, CNAME, TTL)
  • (Name, Domain, MX, TTL) e.g. (mail, mail.163.com, MX, TTL) 禁止指向CNAME

报文构成
DNS Message

电子邮件系统的构成、传输机制和协议

构成与传输机制

Email Architecture
于上图可知，因特网电子邮件系统有三个组成部分：用户代理(User Agent)、邮件服务器(Mail Server)、简单邮件传输协议(Simple Mail Transfer Protocol,SMTP)
一个典型的邮件发送过程是：从发送方的用户代理开始．传输到发送方的邮件服务器、再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。

协议

写不动了自己看吧

TCP 和 UDP 套接字编程

UDP套接字

UDP

UDP Client

1
2
3
4
5
6
7
8
9
10
11
from socket import *  # 导包
serverName = 'localhost'  # 设置服务器主机名
serverPort = 12000  # 设置服务器端口号
# AF_INET代表了IPv4，SOCK_DGRAM代表了这是个UDP的Socket
clientSocket = socket(AF_INET, SOCK_DGRAM)
message = input('Input lowercase sentence')  # 输入要哔哔的话
clientSocket.sendto(message.encode(), (serverName,
                                       serverPort))  # 咱就给您送出去！（顺便编个码）
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)  # 好咧，别人给您的回信来啦！
print(modifiedMessage.decode())  # 看看别人咋哔哔的（顺便解个码）
clientSocket.close()    # 再见了您咧！

UDP Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
from socket import *  # 导包
serverName = 'localhost'  # 设置服务器主机名
serverPort = 12000  # 设置服务器端口号
# AF_INET代表了IPv4，SOCK_DGRAM代表了这是个UDP的Socket
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('', serverPort))  # 绑定IP和端口喔！
print("The Server is ready to recive!")  # 准备好啦！
while True:
    message, clientAddress = clientSocket.recvfrom(2048)  # 好呀，看看谁来信了！
    modifiedMessage = message.decode().upper()  # 解个码变大写！
    serverSocket.sendto(modifiedMessage.encode(),
                        clientAddress)  # 咱就给您送回去！（顺便编个码）

# 惨，Server不能关（?

P2P 文件共享原理

CS VS P2P

P2P 集中式目录

上图中，若在P2P网络中加入一个作为目录（索引）的服务器，为对等方提供检索服务，即为P2P集中式目录(结构)。

  • 单点故障
  • 性能瓶颈
  • 侵犯版权

BitTorrent

BitTorrent 是一种用于文件分发的流行P2P协议。参与一个特定文件分发的所有对等方的集合被称之为一个torrent；在一个torrent中，对等方彼此下载等长度的chunk，典型的chunk长度(size)为256KB。

DHT(Distributed Hash Table)

DHT
使用键值对(Key-Value)进行存储，每个对等方皆能查询(get)与插入(put)。