计算机网络第二章复习
计算机网络第二章复习
1️⃣ 应用层协议原理
overview:应用层协议只在端系统层面实现,不在链路交换机和路由器实现。
如图1-24:

图1-24显示了数据从一台主机到另一台主机的路径,在途径的链路层交换机和路由器只实现了物理层+链路层+(网络层)因此:

应用层只在端系统层面进行了实现:

比较三种应用程序体系结构:
c/s p2p 混合体系

cs为解决服务器压力,配置大量主机的数据中心解决服务器压力--》(什么叫服务器场)

纯P2P体系:

7️⃣ P2P
p2p的概念还是很暧昧,让我们研究一下:
💇♂️研究一个场景,单一服务器向大量主机分发一个大文件

👨❤️👨 c/s体系:
服务器必须向N 个对等方的每个传输该文件的一个副本。因此该服务器必须传输
NF 比特。分发时间是:


👫 BitTorrent

在c/s:该服务器必须向每个对等方发送该文件的一个副本
在p2p:每个对等方能够向任何其他对等方重新分发它已经收到的该文件的任何部分
观察到系统整体的总上载能力等于服务器的上载速率加上每个单独的对等
方的上载速率



✒️ P2P的bittorrent协议详解:
参与一个特定文件分发的所有对等方成为一个洪流
在一个洪流中的对等方彼此下载等长度的文件块chunk
一个块起初加入对等方时,并没有块,随着时间的流逝,它累积了越来越多的块。当它下载块时,也为其他对等方上载了多个块。
每个洪流具有一个基础设施节点,称为追踪器(tracker) 。当一个对等方加入某洪流时,它向追踪器注册自己,并周期性地通知追踪器它仍在该洪流中
当一个新的对等方Alice 加入该洪流,追踪器随机地从参与对等方的集合中选择对等方的一个子集(为了具体起见,设有50 个对等方),并将这50 个对等方的IP 地址发送给Alice 。
Alice 持有对等方的这张列表,试图与该列表上的所有对等方创建并行的TCP 连接。我们称所有这样与Alice 成功地创建一个TCP 连接的对等方为"邻近对等方”
一个对等方的邻近对等方是随时间变化的

周期性的向邻近对等方询问它们所具有的块列表,所以ALice知道自己已有的块和邻居有的块,采用最稀缺优先技术请求邻居的块

优先选择以最高速率向他提供数据的邻居:谁对我好,我对谁好。

此时假定某对等方Alice要将一个(键,值)对插入DHT。从概念上讲,这是直接的:她首先确定标识符最邻近该键的对等方;然后她向那个对等方发送一个报文,指示它存储该(键,值)对。但是Alice怎样确定最邻近该键的对等方呢?如果Alice要联系系统中所有对等方(对等方ID和相应的IP地址),她能够在本地确定最邻近对等方。但是这样的方法要求每个对等方联系在该DHT中的所有其他对等方,而这对于具有数以百万计对等方的大规模系统而言,是完全不现实的。
环形DHT和扰动DHT,最邻近对等方和各种处理

环形DHT,每一个对等方只需要维护自己的直接前任和直接后继
扰动DHT,每一个对等方要再维持一个后继的后继
(From Pig-pupu)对等方是【0-7】,文件块也是【0-7】



宏观上看进程通信:
可供应用程序使用的运输服务:
1.可靠数据传输
2.吞吐量:带宽敏感的应用和弹性应用
3.定时
4.安全性
IP+端口号确定唯一进程
吞吐量:在网络链路上发送进程向接收进程交付比特的速率
带宽:网络所能提供的最大比特传输率(带宽会被共享)
TCP:
UDP:
应用层协议:
应用层协议(application- layer protocol) 定义了运行在不同端系统上的应用程序进程如何相互传递报文。
有些应用层协议是由RFC 文档定义的,因此它们位千公共域中。例如, Web 的应用层协议HTTP (超文本传输协议[ RFC 2616 ]) 就作为一个RFC 可供使用。

2️⃣ web和Http(HyperText Transfer protocol 80):
多数Web 页面含有一个HTML 基本文件(base HTMLfile) 以及几个引用对象。
在请求时不得不先得到那个基本的html才能得到其他的引用
理解web中的浏览器(==客户)
Http是web的核心,http协议定义了怎么请求,怎么传输对象
名词理解:
URL:统一资源定位符 主机名‘www.xxxx.com’+路径名 ‘/myPicture/lsw.png’
HTTP 定义了Web 客户向Web 服务器请求Web 页面的方式,以及服务器向客户传送Web 页面的方式
🔥 持续连接和非持续连接:
🔥理解浏览器请求页面的方式和持续非持续/并行非并行的时延
永远是一个响应一个请求,只是时间上的并行,而不会一个请求,100个同时响应。
a.首先去请求整个的HTML文件:2*RTT

这段时间不是并行的:因为此时尚未获得html上的对象引用
b.若该html包含10个对象的引用
采用非持续连接:
不并行:10个RTT+10个RTT+10个对象传输时间
并行:(假设可以同时并行7个) 2*2RTT+10个对象传输时间
并行:(假设可以同时并行10个) 2RTT+10个对象传输时间
采用持续连接:
非并行:10个RTT(请求响应)+10个对象传输时间
并行(假设可以同时并行7个)RTT+RTT+10个对象传输时间
并行(假设可以同时并行10个)RTT+10个对象传输时间
🔥 web缓存
🔥理解web缓存的意义,计算因特网时延+接入链路时延+局域网时延


✒️ 在书上的计算是通过流量强度,然后告诉我们这个流量强度下的时延大概是多少,并没有真正的计算接入链路和局域网时延

当使用web缓存后:假设命中率为0.4


✒️ 而在课后题中给出了一个式子近似局域网时延和链路时延:(然后去定量的计算响应时间)

HTTP报文格式与条件GET
联动Http请求和响应报文,解决Web缓存带来的非最新,过时问题
Http的请求报文:
对象URL路径 /picture/lsw.png
首部行:Host : 对象主机
user agent :用户浏览器类型
connection-type:持续还是非持续连接

Http的响应报文:
第一个Date是响应时间,第二个last-modified是上一次的修改时间
Http的响应报文是通过content-length标志结束的

Web缓存器发送条件get请求判断当前缓存是否为最新的

然后WEB服务器向缓存发送(只有这个时候的date才表示上次修改的时间,之前普通get的date时间都是响应时间,采用这种条件get的原因是之前的请求响应都包含了数据对象的传输,耗时,而条件get的实体为empty,大大减少了时间)

3️⃣电子邮件SMTP:25
SMTP的限制:7位的ASCII码
区分推协议和拉协议: HTTP是一个拉协议,SMTP是一个推协议

邮件发送的特点:不经过中间商赚差价

发送一封邮件到接收的全过程:

A打开发送方邮件代理,提供bob的邮箱地址,码字,告诉用户代理发出去
A的邮件服务上的SMTP客户端发现了报文队列的这个报文,
A的邮件服务器的SMTP客户端创建一个TCP连接到B的邮件服务器的SMTP服务端的连接
SMTP握手后报文被发送(如果Bob 的邮件服务器处于开启,不然缓存在A的邮件服务器),B的SMTP服务器接收报文并放入b的邮箱
在Bob 方便的时候,他调用用户代理阅读该报文。
比如POP3:用户代理发出特许阶段的
的两个命令登录到邮箱,然后可以使用命令list,retr,dele对报文处理
基于WEB的电子邮件
中间还是SMTP,两端都是HTTP
4️⃣ DNS(domain name system:53 udp)
DNS黑盒:
1.我们的电脑上运行着DNS应用的客户端
2.当我们在浏览器输入网址,浏览器从上述URL 中抽取出主机名www. son1eschool. edu 、并将这台主机名传给DNS 应用的客户端。
3.客户端把主机名传给服务器,经过DNS一系列递归查询,迭代查询,我们得到了Ip地址并且最后返回到了浏览器,现在就可以发起TCP连接了
从这个例子中,我们可以看到DNS 给使用它的因特网应用带来了额外的时延,有时
还相当可观。幸运的是,如我们下面讨论的那样,想获得的IP 地址通常就缓存在一个
“附近的"DNS 服务器中,这有助于减少DNS 的网络流量和DNS 的平均时延。
DNS提供的其他服务:
主机别名:A
邮件服务器别名:MX
负载分配:
繁忙的站点(如cnn. com) 被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上,每个都有着不同的IP 地址。由千这些冗余的Web 服务器, 一个IP 地址集合因此与同一个规范主机名相联系
该服务器用IP 地址的整个集合进行响应,但在每个回答中循环这些地址次序。因为客户通常总是向IP 地址排在最前面的服务器发送HTTP 请求报文,所以DNS 就在所有这些冗余的Web 服务器之间循环分配了负载。DNS 的循环同样可以用千邮件服务器,因此,多个邮件服务器可以具有相同的别名。
DNS的工作原理
迭代查询和递归查询:


DNS的记录和报文

如果Type= NS, 则Name 是个域(如foo. com) , (foo. com_, dns. f oo. con1, NS) 就是一条类型为NS 的记录。
向DNS数据库插入记录

5️⃣ 视频流和内容分发网络
Http的动态适应流DASH
当用户要看该视频时, 客户与服务器创建一个TCP 连接并发送对该 URL的HTTP GET 请求。
这确实没什么问题,但为了客户更好的体验:


内容分发网:(我真心看不懂)
- [ ]

集群选择策略:
地理上最邻近和当前流量情况最好
6️⃣ 套接字编程
直接看代码····手动写一些

浙公网安备 33010602011771号