正在学习计算机网络课程，以下是学习《计算机网络-自顶向下方法》的一些笔记，部分图片来自mooc网 哈尔滨工业大学 计算机网络课程：https://www.icourse163.org/course/HIT-154005。
文章目录
1.网络应用的基本原理
1.1网络应用的体系结构
- 客户机/服务器结构（Client / Server）
- 服务器：永久性访问地址和域名；利用大量服务器实现可扩展性；7*24小时提供服务
- 客户机：与服务器通信，使用服务器提供的服务；间歇性接入网络；可能是有动态IP地址；不会与其他客户机直接通信
- 点对点结构（Peer-to-Peer，P2P）
- 没有永远在线的服务器
- 任意端系统/节点之间可直接通信
- 节点间歇性接入网络
- 节点可能改变IP地址
- 混合结构（Hybrid）
1.2网络应用的进程通信
- 同一主机上的不同进程如何通信？：由操作系统负责调度，遵循进程间通信机制
- 不同主机上运行的进程如何通信？：消息交换/报文交换
- 进程间通信使用Socket套接字进行接收/发送消息，是操作系统提供的网络编程的API，过程类似与日常生活中的寄信。
- 进程间通信要依赖消息交换，那底层的基础设施如何进行寻址的呢？（进程的标识符：IP地址 + 端口号）
- IP地址唯一标识主机；
- 端口号（Port Number）标识主机上的不同进程：HTTP Server 80，Mail Server 25…
- 消息交换的格式、顺序等规则？
- 网络应用需要遵循应用层协议
- 公开协议，如HTTP、SMTP…，由RFC：Request For Comments定义，只要遵循这个协议，就允许相互操作访问
- 当然也有一些私有协议
- 应用层协议的内容
- 消息的类型：请求消息、相应信息
- 消息的语法格式：要包含哪些字段、字段如何描述
- 字段的语义：字段中信息的含义
- 规则：进程何时发送/响应消息、进程如何发送/响应消息
- 网络应用需要遵循应用层协议
1.3网络应用的需求
- 网络应用对传输服务 的需求：
- Internet 提供的传输服务
2.Web应用
2.1 Web应用概述
- 网页（Web Page）包含多个对象：HTML文件、JPEG图片、视频文件、动态脚本等
- 对象的寻址：统一资源定位符（URL，Uniform Resource Locator）
- Scheme : // host : port / path
- 万维网Web应用遵循的协议：超文本传输协议（HTTP，HyperText Transfer Protocol）
- 该协议采用C/S架构
- 客户 Browser：请求、接收、展示Web对象
- 服务器 Server：响应客户的请求，发送对象
- HTTP版本：
- 1.0：RFC 1945；
- 1.1：RFC 2068
- HTTP应用层协议采用的传输层协议：TCP
- 服务器在80端口等待
- 浏览器发起到服务器的TCP连接（创建套接字Socket）
- 服务器接受来自浏览器的TCP连接
- 浏览器与服务器交换HTTP消息
- 关闭TCP连接
- 服务器不维护任何有关客户端过去所发请求的消息：HTTP是一个无状态（stateless）协议
2.2HTTP连接类型
- 非持久性连接（Nonpersistent HTTP）
- 每个TCP连接最多允许传输一个对象
- HTTP 1.0 版本使用
- 持久性连接（Persistent HTTP）
- 每个TCP连接允许传输多个对象
- HTTP 1.1 版本使用
- RTT（Round Trip Time）：从客户端发送一个小的数据包到服务器并返回所经历的时间
- 非持久性连接获得一个对象的时间：Total = 2*RTT+文件发送时间。太慢！开销资源太多。改进：采用持久性连接。
- 持久性连接
- 无流水的持久性连接：客户端只有收到前一个响应后才发送新的请求，获得每个被引用的对象需要一个RTT
- 流水机制的持久性连接：HTTP 1.1默认选项，客户端只要遇到一个应用对象就尽快发出请求，理想情况下收到所有引用对象只需要耗时1个RTT
2.3 HTTP消息格式
- 两类消息：请求消息、响应消息，由ASCII码写，人类直接可读，
- 请求消息：
- method类型：
- HTTP 1.0： GET、POST、HEAD（请Server不要将所请求的对象放入响应消息中，一般做测试用）
- HTTP 1.1：GET、POST、HEAD、PUT（把消息体里的文件上传到URL字段所指定的路径） 、DELETE（删除URL字段所指定的文件）
- 响应消息：
- HTTP响应状态代码（位于响应消息的第一行）
- 100-199 用于指定客户端应相应的某些动作（提示信息）
- 200-299 用于表示请求成功 eg：200 OK
- 300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息 （重定向）eg：301 Move Permanently
- 400-499 用于指出客户端的错误 eg：400 Bad Request（请求出现语法错误）、404 Not Found
- 500-599 用于指出服务器段的错误 eg：505 HTTP Version Not Supported 服务器不支持请求中所指明的HTTP版本
2.4 Cookie技术
前面提到了 HTTP 服务器是无状态的。 这简化了服务器的设计，并且允许工程们去开发可以同时处理数以千计的 TCP 连接的高性能 Web 服务器。 然而一个 Web 站点通常希望能够识别用户，比如网上购物里的购物车。
为此.，HTTP 使用了 cookie技术，它允许站点对用户进行眼踪， 目前大多数商务 Web 站点都使用了 cookie。
- cookie技术有四个组件：
- 在 HTTP 响应报文中的一个 cookie 首部行
- 在 HTTP 请求报文中的一个 cookie 首部行
- 在用户端系统中保留有一个 cookie 文件，并由用户的浏览器进行管理
- 位于 Web 站点的一个后端数据库
- cookie技术的场景：
- 身份认证
- 购物车
- 推荐
- web Email
- 存在隐私问题
2.5 Web 缓存（Web Cache）/代理服务器（proxy server）技术
- 功能：在不访问服务器的前提下满足客户端的HTTP请求
- 为什么发明这项技术？——从性能上考虑
- 缩短客户请求的响应时间
- 减少机构、组织的流量
- 在大范围内（Internet）实现有效的内容分发
- 假设浏览器正在请求对象 ：
- 浏览器建立一个到 Web 缓存器的 TCP 连接，并向 Web 缓存器中的对象发送一个 HTTP 请求。
- Web 缓存器进行检查，看看本地是否存储了该对象副本。 如果有， Web 缓存器就向客户浏览器用 HTTP 响应报文返回该对象。
- 如果 Web缓存器中没有该对象，它就打开一个与该对象的初始服务器的TCP 连接，发送请求，获取对象，返回给客户端并将该对象保存在本地
- 缓存既充当客户端也充当服务器
- 一般由ISP（Internet服务提供商）架设。 例如， 一所大学可能在它的校园网上安装一台缓存器，并且将所有校园网上的用户浏览器配置为指向它。
- 条件GET方法：高速缓存能减少用户感受到的响应时间，但也引人了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。
- 解决： HTTP协议有一种机制，允许缓存器证实它的对象是最新的。 这种机制就是条件 GET (conditional GET) 方法
- 具体：①请求报文使用 GET 方法;并且②请求报文中包 含一个"If-Modified -Since : "首部行。那么，这个 HTTP 请求报文就是一个条件GET 请求报文。
- 若缓存中的对象是最新的 ，则服务器的响应消息中不包含对象，在响应报文中，状态行中为 304 Not Modified，它告诉缓存器可以使用该对象，能向请求的浏览器转发该对象副本。
3.Email应用
3.1 Email应用概述
- Email应用的构成组件：
- 邮件代理（user agent）
- 邮件服务器（mail server）
- 邮箱（mailbox）：管理和存储着发送给用户的报文。
- 报文队列( message queue)：存储等待发送的Email，通常每 30 分钟左右尝试一次发送；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方
- SMTP协议（Simple Mail Transfer Protocol）
- 使用TCP进行Email的可靠传输
- 端口25
- 握手——消息传输——关闭
- 采用命令/响应交互模式（HTTP采用请求/响应）
- SMTP 一般不使用中间邮件服务器发送邮件，即使这两个 邮件服务器位于地球的两端也是这样。
- 例子：
- 发送方 Alice 发电子邮件给接收方 Bob
- 当Alice 完成邮件撰写时，她的邮件代理向其邮件服务器发送邮件，此时邮件放在邮件服务器的外出报文队列中。
- 发送方Alice的邮件服务器将邮件传输到接收方Bob的邮件服务器，然后在这里被分发到接收方Bob的邮箱中。
- 典型的异步交互
- SMTP与HTTP的比较：
- 都用于从一台主机向另一台主机传送文件。
- 当进行文件传送时，持续的 HTTP 和 SMTP 都使用持续连接。
- HTTP 主要是一个拉协议 (pull protocol) , 即在方便的时候，某些人在 Web 服务器上装载信息，用户使用 HTTP 从该服务器拉取这些信息。 特别是 TCP 连接是由想接收文件的机器发起的。
- SMTP 基本上是一个推协议 (push protocol) ，即发送邮件服务器把文件推向接收邮件服务器。特别是，这个 TCP 连接是由要发送该文件的机器发起的。
- SMTP 要求每个报文(包括它们的体)使用 7 比特 ASCII 码格式。 如果HTTP 数据则不受这种限制。
- 对于一个既包含文本又包含图形的文档，HTTP 把每个对象封装到它自己的 HTTP 响应报文中， 而 SMTP 则把所有报文对象放在一个报文之中。
3.2 Email消息格式与POP协议
- 文本消息格式标准：
- 头部行（header）
- To
- From
- Subject
- 空白行
- 消息体（body）
- 消息本身（只能是ASCII字符）
- 头部行（header）
- 邮件包含多媒体等非文本格式怎么办？——MIME
- MIME（Multipurpose Internet Mail Extensions）多媒体邮件扩展：通过在邮件头部增加额外的行以声明MIME的内容类型
- 根据声明的编码方法把文件编码成ASCII码，收件人根据编码方法把ASCII数据解码
- SMTP 将邮件报文从Alice 的邮件服务器交付给 Bob 的邮件服务器，该报文就被放入了 Bob 的邮箱中。收件人Bob从邮件服务器上收邮件时采用的不是SMTP协议，而是邮件访问协议
- POP（POSl Office Protocol）邮局协议
- 极为简单
- 认证/授权（客户端——服务器）和下载
- 无状态
- IMAP（Intemet Mail Access Protocol ）因特网邮件访问协议
- 所有消息保存在一个地方：服务器
- 允许用户通过文件夹组织消息
- 支持跨会话的用户状态
- HTTP：163、QQ Mail等
- POP（POSl Office Protocol）邮局协议
4.DNS应用：因特网的目录服务
4.1 DNS概述
- Internet中主机或路由器的标识（两套方案）：
- IP地址：数字，用户不容易记住
- 域名：方便用户记忆，更好识别如www.baidu.com
- 在网络层中使用的是IP地址，而人使用的是域名，因此二者需要建立映射关系——DNS负责
- DNS（Domain Name System）域名解析系统
- 多层命名服务器构成的分布式数据库
- 一个使得主机能够查询分布式数据库的应用层协议。
- DNS 服务器通常是运行 BIND (Berkeley Internet Name Domain) 软件的 UNIX机器。 DNS 协议运行在 UDP 之上，使用 53 号端口
- 分布式、层次数据库：
- 根DNS域名服务器，在因特网上有 13 个根 DNS 服务器(标号为 A 到 M) ，它们中的大部分位于北美洲。
- 顶级DNS域名服务器，这些服务器负责顶级域名如 com、 org、 net、 edu ，以及所有国家的顶级域名如uk、fr、ca 和 jpo。由一些组织或公司维护。
- 权威 DNS 服务器， 组织的域名解析服务器，只要对外提供服务，就要维护。如多数大学和大公司实现和维护它们自己基本和辅助(备份)的权威 DN 服务器。
- 本地DNS服务器，严格说来并不属于该服务器的层次结构，但它对 DNS 层次结构是重要的。 每个 ISP (如一个大学、一个公司或一个居民区的 ISP) 都有一台本地 DNS 服务器(也叫默认域名服务器) 。作为代理和缓存
- DNS查询示例：
- 从请求主机到本地 DNS 服务器的查询是递归的，其余的查询是迭代的。
- 递归查询
- 从请求主机到本地 DNS 服务器的查询是递归的，其余的查询是迭代的。
- DNS 缓存与更新
- DNS 缓存原理非常简单。 在一个请求链中，当某 DNS 服务器接收一个 DNS 回答（IP地址与域名的映射）时，它能将该回答中的信息缓存在本地存储器中。 一段时间后，缓存失效
- DNS提供的其他服务：
- 主机别名 (host aliasing) ，有着复杂主机名的主机能拥有一个或者多个别名
- 邮件服务器别名 (mail server aliasing)
- 负载分配 (load distribution)
- 为什么使用分布式不使用集中式？
- 单点故障 (a single point of failure) 。 如果该 DNS 服务器崩溃，整个因特网随之瘫痪!
- 通信容量( traffic volume) 。 单个 DNS 服务器不得不处理所有的 DNS 查询(用于为上亿台主机产生的所有 HTTP 请求报文和电子邮件报文服务) 。
- 远距离的集中式数据库 (distant centralized database) 。 单个 DNS 服务器不可能 "邻近"所有查询客户 。 如果我们将单台 DNS 服务器放在纽约市，那么所有来自 澳大利亚的查询必须传播到地球的另一边，中间也许还要经过低速和拥塞的链路。 这将导致严重的时延。
- 维护 (maintenance) 。 单个DNS服务器将不得不为所有的因特网主机保留记录。 这不仅将使这个中央数据库非常庞大，而且它还不得不为解决每个新添加的主机 而频繁更新。
4.2 DNS记录与消息格式
- RR（resource records）资源记录：RR 提供了主机名到 IP地址的映射。 每个 DNS 回答报文包含了一条或多条资源记录。
- 资源记录是一个包含了下列字段的 4 元组：（Name, Value , Type , TTL）
- TTL 是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。
- Name 和 Value 的值取决于 Type：
- Type =A ，则 Name：主机域名， Value：IP地址
- Type = NS ，则 Name ：域（如 edu. cn）， Value：该域权威域名解析服务器的主机域名
- Type = CNAME ，则Name：某一真实域名的别名，Value：真实域名
- Type = MX，Value是与Name相对应的邮件服务器
- DNS有自己的协议：DNS协议
- 查询/回复性协议
- 两者消息格式相同
4.3 在 DNS 数据库中插入记录
- 假定你刚刚创建一个称为网络乌托邦 (Network Utopia) 的令人兴奋的新创业公司。 你必定要做的第一件事是在注册登记机构 ( registrar )注册域名： networkutopia. com
- 注册登记机构 ( registrar )是一个商业实体， 它验证该域名的唯一性，将该域名输入 DNS 数据库，对提供的服务收取少量费用。
- 步骤：
- 向域名管理机构提供你的权威域名解析服务器的名字和IP地址
- 域名管理机构向 com 顶级域名解析服务器中插入两条记录（前面讲过的RR）：
(networkutopia.com, dns1.networkutopia.com, NS) ——域名和权威域名解析服务器的主机域名
(dns1.networkutopia.com, 212.212.212 .1, A) ——主机域名和 IP 地址 - 还要确保用于 Web 服务器 www. networkulopia. com 的类型 A 资源记录和用于邮件服务器 mail. networkutopia. com 的类型 MX 资源记录被输入到自己的权威 DNS 服务器中。
- 完成所有这些步骤，人们将能够访问你的 Web 站点，并向你公司的雇员发送电子邮件。
- 例子：
- 假定在澳大利亚的Alice 要观看www. networkutopía. com 的 Web 页 面。
- 如前面所讨论，她的主机将首先向其本地 DNS 服务器发送请求。
- 该本地服务器接着 则联系一个 TLD com （顶级）服务器。 (如果 TLD com 服务器的地址没有被缓存，该本地 DNS 服务 器也将必须与根 DNS 服务器相联系）
- 该 TLD 服务器包含前面列出的类型 NS 和类型 A 资 源记录，因为注册登记机构将这些资源记录插入所有的 TLD com 服务器。 该 TLD com 服务 器向Alíce 的本地 DNS 服务器发送一个回答，该回答包含了这两条资源记录。
- 该本地 DNS 服务器则向 212. 212. 212. 1 发送一个 DNS 查询，请求对应于 www. networkutopia. com 的类型 A 记录。 该记录提供了所希望的 Web 服务器的 IP 地址，如 212.212.71. 4 ，本地 DNS 服 务器将该地址回传给Alice 的主机。
- Alice 的浏览器此时能够向主机212.212. 71. 4 发起一个 TCP 连接，并在该连接上发送一个町rTP 请求。
扫一扫
1906
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
