牢景的计算机网络学习笔记(1)——应用层(5.19完结)

写文初衷 :记录一下自己的学习过程,存一份电子笔记,方便自己复习。

学习思路:本来想跟着cs144过一遍然后写lab,从头撸一个tcp协议栈来着,奈何时间分配以及听课环境都不是很好,遂只学了个整体框架。最后还是看的中科大郑老师的课,以及结合八股进行学习。 初步目标是理解并记忆八股即可。(重点是os,对于后端来说,计网的一些内容可能相对没那么重要?)


cs144

网络层:

life of a packet:


 

不要看目录 第一次搞不大会  全乱了

特别鸣谢:部分借鉴dalao   

 @

wbl_z
​​​​​​​的笔记

                   

科大:

 


应用层架构

大纲:

1.web与HTTP  

2.*FTP

3.*Email

4.DNS

5.P2P应用

6.*CDN

0.应用层体系结构

0.1网络应用在端系统中部署

C/S  客户端-服务器

P2P  点对点  

混合体  napster 、即时通信

其实这三张ppt就几乎涵盖了所有应用层的模式

0.2.分布式进程要解决的三个问题

2.1进程的标示和寻址问题(how)

解决 :对进程编址SAP(3要素) 

主机    唯一 32位 Ip地址

协议   TCP or UDP

端口号  eg HTTP:TCP 80

本质上是由端口号来区分不同的应用进程TCP/UDP均为16bit的端口号

2.2传输层-应用层提供服务

解决: 需要穿过的层间信息(3)

层间接口必养的角色(bushi):

SDU ,谁传的(IP+ TCP(UDP)端口),传给谁(对方的IP+ TCP(UDP)端口

TCP/UDP实体封装 源和目的 的端口号和数据,进一步交给IP实体来封装源IP和目标IP

 为了减少层间传送的信息量,后面二者可以用socket表示                         

                                              

                                                       socket(四元组的一个具有本地意义的标示)   //udp二元

是一个整数  

TCP socket 代表了源ip 目标ip 源port 目标port

Udp socket 代表了源ip 源port

这个就是封装

封装的好处  减少层间传送的信息量,只用 socket+UDP即可

这是应用层和传输层你我彼此的小约定哦~,对方不需要知道socket

 

建立连接时操作系统返回一个socket整数,OS根据socket表就知道上面的四元组,也即在传输层可以得到对应的四元组

接收的时候根据收到的四元组,可以根据建立起的socket的表找到对应的socket,再找到哪个应用进程创建了这个socket,从而把数据发给相应的应用进程

TCP socket

·四元组

·唯一指定两个进程的回话关系

·作为通信的标示

·不必每次发送都指定一次

·简单

  udP socket

·无连接,独立传输 ,前后报文可能传向不同进程

·只代表本IP 本端口

·所以在层间传输的时候 ,还需要对方的ip和端口,便于定位

因此发送报文时应用层的应用进程传给传输层的UDP实体需要三个信息:UDP socket、目标IP和端口、SDU
同理在接收报文时传输层要将对方的IPport传给对应的应用进程,让其知道是谁传来的

2.3如何用传输层的服务,实现应用层的报文转换?

解决 :

·定义应用层协议  (实体,规范) 

如HTTP

·编制程序

所以,应用需要传输层提供什么样的信息呢?

TCP 服务 :
1.可靠的传输服务2.流量控制机制3.拥塞控制机制4.面向连接

不过上面ppt的服务,tcp做不到捏

Udp服务

1.不可靠的传输服务2.不能做到:可靠,流量控制,拥塞控制,连接,时间,带宽保证

补充:不是应用层  但提一嘴

UDP 存在的必要性   可以区分不同的进程  而IP 服务不可以 所以不可以被IP替代,ta不可靠,也就是不会检错重发,适用于那些对正确率要求不高的应用

也无连接  ,省去了建立连接的时间

没有拥塞控制和流量控制,也可以保证它按照原速度传送,特别适用于直播!

·安全TCP  

SSL 在TCP上实现  加密  应用层中

1.Web与HTTP

web是一种应用,http是支持web应用的协议

 大纲

·HTTP连接

·http报文

·Cookies  用户-服务器状态 记录一些数据到浏览器

请求响应模型

·Web缓存(代理服务器)

·URL (统一资源定位符  区分URI ) 就记一个是地址 一个是身份证就行

内容(协议名 主机名 路径名 端口 参数。。。)

·HTTP连接

·超文本传输协议

·C/S模式

·使用tcp

·无状态 (不维护)

HTTP连接分类

·非持久HTTP 

一个对象跑一个TCP连接 ,连接玩撤桥

 至少花两次RTT (一次连接TCP,一次传数据)+传输时间

HTTP1.0采用

·持久HTTP 

多个对象可以跑一个 tcp

  发送请求完之后  TCP连接暂时不撤销

HTTP1.1采用

 非流水线方式的持久HTTP

流水线方式的持久HTTP 

客户端不等待对象回来,而是发出第一个请求后再发出第二个请求,之后对象依次回来。HTTP 1.1默认方式

·HTTP请求报文

两种报文都是ASCII码可读的,都是用ASCII编码的

请求报文格式

·请求行

·首部行

·回车

·实体行

具体的 方法类型

GET POST PUT DELETE

·HTTP响应报文

·状态行  

协议版本,状态码,状态信息(对状态码的解释,如OK)

·首部行

包含Last-Modified 记录修改时间,从而保证后面所讲的缓存能够与服务器内容保持一致

·回车

·数据

·web缓存

目标:不访问原石服务器 就能满足客户的要求

特点 :有对象直接返回 ,没有的话 ta去请求原始服务器

既是客户端 ,又是服务器

好处 快 这个没的说 ,你直接查表能不快吗 ,减少内网与Internet接入上的流量,减少服务器压力。访问的少了,服务器也安生(doge)

有风险 : 服务器改变了,但是缓存没变呢

解决:因此proxy server会使用Conditional GET向服务器发送请求,并在头部加入了**If-modified-since: **的条件

如果没有修改,那么服务器返回304 Not Modified表示没有修改;如果修改了,那么就和GET命令完全一样,将对象返回给proxy server 200 OK

Cookie

TCP不管http报文的内容,所以让应用层http自己区分这些字节流的结构

Cookies弥补了HTTP无状态带来的一些问题

 在一次会话的生命周期内,服务器端会给客户端分配一个cookie,并存在数据库里面。客户端收到cookies由浏览器保管。  客户端再次请求时会在请求报文头部带上这个cookie,服务器端会根据不同的cookie区分不同的客户端端对象,

FTP 还没仔细看  感觉八股看到的不多喵?

· DNS   域名解析 唯一真神  一个绝对nb的架构

首先功能

 实现域名到IP地址的转换 主要是给机器看的  这是最核心的

  其次功能 

服务器别名对应到正规名字(服务器本身的机名)

实现负载均衡   在主机别名到规范命名时选择负载较小的服务器

DNS 要解决的问题  (什么? 我 我打URL?)

1.如何命名设备

2.如何完成名字到IP地址的转换

3.如何维护,增加or删除一个域,要在域名系统中做那些工作?

DNS的主要特点

1.分层的 基于域的命名

2.若干分布式的数据库完成    名字--》ip

3.运行在UDP上端口号为53的应用服务

4.核心的Internet 功能 但是以应用层协议实现

提一嘴:互联网的很多核心功能都是在网络边缘的端系统的应用层进程实现的

ask1

要知道

域名用平面化的命名很容易重复,因此应该使用层次化的命名

使用一台设备解析域名是不可行的,因此分布式的维护和解析域名(多个服务器)

别名 比如baidu.com 虽然每次访问都是输这个URL 但是它可不是对应唯一的服务器吧 ,每次对应的可能是不同的服务器。但是你无需知道那个具体的服务器的IP

就好比点外卖 ,你只要上美团下单就行,不用知道是那个骑手为你服务

DNS域名结构  。

主机命名从树叶往树根走,每过一层加一个dot.区分

命名从树枝往上走,每过一层加一个dot.区分

如果只有一个root,那么万一宕机了,那么全部都不能使用,因此一共有13个根域名服务器,可以从最近的开始root往下找,如果宕机了,可以换成别的root。【事实上有上百台根域名服务器,由 13 个机构维护,逻辑上是 13 个根域名服务器】

根名字服务器

整个命名体系是一个树的结构 天才的思想  ,实现了分层,避免了同层重名的问题,而且全世界有13个树根 ,节点与树高的关系又是log级别 ,这样就实现了唯一对应

树叶 是主机  每通过一层加一个dot ,从叶子走到根就是域名

补充一下域

域与物理网络无关 。就算我在我宿舍里,也可以运行一台欧美国家域名的主机,只要那头的链接是正常的。

所以 同一个域的主机可以在不同网络上,同一个网络的主机,也可以属于不同的域。

(店叫什么名字 跟在哪里开店没关系吧)

主要看IP

不过显然有问题  :要是服务器根挂了怎么办?节点太多 存储不够爆了空间怎么办?远距离怎么维护?

Ask2

引入概念:区域

每一个区域用一台名字服务器维护

在区域里  名字服务器就是权威

身为领导,要维护一个指针,告诉其他人从上级到下级怎么走捏

NS即上层域中要保存其子域的指针,保存了子域所属的权威服务器的域名,因此要访问这个DNS服务器,还需要有一条TYPE=A的记录来得到这个服务器的IP地址

除了A以外的TYPE都是得到名字

通过“资源记录”RR 实现。

     作用: 维护 域名---IP 的映射关系  直观理解就是实现了map的功能

   位置 : Name Server 的分布式数据库中

TTL (生存时间   ) 如果是无穷 说明是权威的名字服务器

反之  就是别的区域的名字服务器的记录,是缓存在这里的,为的是提高性能和速度默认生存时间为22天后就会把记录删除为的是保持和权威服务器的一致性

记住 缓冲是为了性能  而 删除是为了一致性

 设备上网四信息   default gateway  主机IP  子网掩码 local name server

怎么查询  递归查询

本地域名服务器并不严格属于层次结构  ,但它是你主机进行dns通信 的直接对象,起到代理的作用,本地域名服务器离用户较近 ,本地域名服务器的IP地址需要直接配置在需要域名解析的主机中。

名字解析过程

递归查询

迭代查询(我愿意称之为踢皮球查询)

DNS报文格式

  查询报文和响应报文的格式相同

·标示符ID 16位

·flags

ID号可以使得查询过程流水线化,如果没有ID号,那么必须等上次查询完成才能发出下次的查询(类比一下HTTP的流水线式)

DNS查询和响应的报文格式一样,根据flags判断是查询还是响应

ASK3

增加或者删除一个域

 

P2P模式

直观定量感受一下下载速度

一般 的cs模式                Tmax=(F/dr ,N*F/us) 随着n增大  下载时间线性增加

但伟大的p2p模式不会坐视不管

核心优化  请求资源的节点又是提供服务的节点

    TMax =(F/dr, F/us, N*F/(us+N*u))

                  第一次上载

流媒体也是类似的,因此一个视频看的人越多反而越流畅

P2P的管理模式

非结构化P2P

就是节点和节点直接的连接是任意的,就相当于图

集中式目录

目录服务器维护了哪些IP在线;哪些IP具有哪些资源

文件传输是分散的 ,定位内容是高度集中的

存在问题:单点故障,性能问题,侵犯版权

完全分布式

一个主机向与之逻辑上连接的所有主机发出查询(假定已经构成了覆盖网),然后一传十,十传百的形式泛洪flooding查询。

会使用TTL来限制泛洪的跳数;或者记录自己已经查询过了,避免回环

覆盖网的构建:在下载Gnutella软件时会有一个配置文件,其中记录最常用的10个节点,本主机向这些节点发送ping,如果这些节点中有在线的,再向它的所有邻居发送ping,和上面的泛洪一样,所有收到ping的节点以pong回应,本主机只要选择若干个节点建立TCP连接当作邻居即可。

当一个节点退出时,只要向其邻居发送即可,这些邻居各自再去找一个新的邻居以维持邻居树目

 就像外卖小哥一样 ,我先下线一会,通知同事送餐,一传十,十传百

 

 混合体

简单来说,就是分小组长,无数个小的集中式

组内使用集中式,组长之间采用分布式

例子BitTorrent

非结构化P2P,可以看作混合体式

把文件分成若干个256KB的块

BT工作原理:在文件网站/搜索引擎中下载torrent文件,其中包含了对应文件的Tracker Server,然后向Tracker Server发出请求,它会分配一些peer节点的列表给请求客户端,从而请求客户端加入洪流,互通有无:拿出自己多余的东西给对方,与之进行交换,以得到自己所缺少的东西

Torrent洪流:相当于一个小组

BitMap标识一个文件的块的拥有情况,比如10表示拥有这个文件的第一个块,但没有第二个块。通过bitmap交换就可以知道相互之间的块的拥有情况

新加入Torrent的节点随机的向其他的节点请求块,因为此时什么都没有,bitmap都是0,当达到41后,优先请求稀缺的块,即在洪流中持有该块的节点数目很少的块。这样可以让稀缺的块逐渐不稀缺,有利于集体利益

并且有一个策略:如果作为服务方,会优先向为我提供服务最好的节点提供服务,是一种你对我好,我对你好的模式

因此新加入的节点得到稀缺块后,别人向他请求的会更多,那么根据策略,他得到别人服务的机会会更大,这样就可以将集体的利益转化成个人利益

因为请求的节点数大于能服务的节点数,所以需要排队,Alice每隔30s随机选择一个节点,而不是根据之前周期该节点对Alice提供的服务进行评估优先选择。这样优化疏通可能可以导致如下的情况

 

结构化P2P

节点与节点之间是可以构成环,树的关系,是有结构的

如环状:每个节点将其IP地址做哈希,根据hash值从小到大首位相连(逻辑),然后文件也同样做哈希,约定好如上面hash值为6~88的文件存储在hash为88的peer节点中。这样的P2P网络模式有效减少了资源定位的开销,提高了P2P 网络的可扩展性

————————————————

                            

  • 4
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值