2、计算机网络之应用层笔记（基于中科院郑老师和计算机网络自顶向下方法）

应用层协议一些概述

应用层开始：

传输层向应用层提供的调用服务的形式其实就是socket api，或者说，原语。
应用层的协议是最多的

应用程序体系结构可以分成两种主流的体系结构

1、C/S模型，即为客户-服务器体系结构

这个的一个经典的例子是web应用程序。除此之外还有FTP、Telnet和电子邮件。
服务器一直运，具有固定的、周知的ip地址，客户端去服务器请求资源，客户端相互之间不直接通信
存在的问题：可扩展性比较差。比如几万人来访问，我可能支持不住，就要扩容，扩内存啥的。当性能达到一个阈值的时候，是断崖式下降，不是说随着人数、访问量的增加缓慢下降。

2、 第二个是P2P系统

就是一个东东又可以当服务器又可以当客户端，看面向谁。所以这个的性能是随着人数的增加，或者说需求？的增加是缓慢下降。
他的优点是自扩展性很好，意思就是不用庞大的服务器和带宽。
问题就是，管理起来很困难。

3、 第三种，混合体

就有点像客户端之间可以互相通信的C/S模式
有领导的P2P模式
一种混搭的感觉

进程通信

进行通信的实际上市进程而不是程序。
应用要跑起来需要网络提供应用进程之间的通信。
如果两个进程在一个设备上，就不用借助网络，可以使用操作系统去控制。（比如你的电脑，开一个网页和开一个qq是两个进程在一个电脑上，肯定就不是网络控制啊，是你的电脑的操作系统在控制）
如果两个进程不在一个端系统上，那就需要借助网络，进行跨越计算机网络交换报文的通信。（至于怎么交换报文就是后面会写讲到的事情了）

发起通信的进程（主动的）叫客户端进程，等待的给回复的是（服务器）服务器进程。
在P2P中，每个p即是客户端也是服务器。

进程和进程间是如何通信的呢？
套接字
进程通过一个称为套接字的软件接口向网络发送报文和接收报文。套接字就像是进程的门，靠这个进进出出。

分布式通信中要解决哪些问题

（这里的分布式，我感觉就是字面意义上的，端节点到处分布，然后进行的通信）

1、应用进程需要标识，通过标识才能找到。（进程的标识和寻址）

这个标识需要具备一些地址信息，完成寻址的作用。
在TCP/IP，标识和寻址包含以下：在哪（ip地址），进程基于tcp还是udp，在tcp又是在哪个端口上。
三个主要要素：主机ip、tcp还是udp、tcp/udp的端口号
一个进程和另一个进程的会话关系由端节点决定。端节点（endpoint）

2、应用通过层间接口，基于下层的服务向对方传送报文。下层（也就是传输层）所提供怎样的服务形式，如何去调用/使用？

这边就是应用层调socket api去调用传输层提供的服务。
地点指的就是SIP（服务访问点）
层间接口需要包含的信息：发的什么（数据本身SDU），谁发的（IP+TCP/UDP端口），发给谁（IP+TCP/UDP端口）
socket是应用层和网络层之间的一种约定 便于管理的一种约定
为了减少穿过层间的信息量，可以通过socket
TCP socket的值是一个整数，但是他代表的是一个通信关系的四元组。




UDP socket
是个二元组，因为UDP它不是面向连接的

3、基于前两点都实现的情况下，如何定义协议，去实现网络的应用。

应用协议仅仅是应用的一部分，应用还可能有界面、IO、操作逻辑这些。
应用协议是控制和网络相关的一些交互动作，
应用协议分为：专有协议和私有协议

有些应用对延时比较敏感（比如视频啊，直播啊，打游戏啊）
TCP和UDP是明文的，没加密

Web和HTTP

web的应用层协议是HTTP（超文本传输协议），他是web的核心。

端口是80

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送页面的方式。

HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。客户向他的套接字接口发送一个请求报文，该报文就脱离了客户控制并进入TCP的控制。

关于你输入url然后访问web服务器的整个流程
1、输入一个url网址请求数据，浏览器根据规则对整个url进行解析，生成请求消息
2、本地协议栈会将这个消息进行层层封装，将包交给网卡，网卡转换成电信号发送出去
3、这些信号会经过交换机、路由器等设备，就是骨干网络。这里还涉及到路由转发，会送到对的路由的道路去。
4、数据来到了正确的服务器所在的局域网，在这里又会变成包，然后去经过防火墙的筛查。经过防火墙后，还有可能遇到缓存服务器，大概的目的就是为了提高性能。如果数据在这个里面就直接拿到再送回去。没有就去到web服务器拿到再送回去。

HTTP 超文本传输协议
首先客户端和服务器建立tcp连接，然后客户端发送http请求，然后web服务器接收到了这个请求，把请求的东西再封装成http报文发送回去。
HTTP跑在TCP之上

HTTP连接

每个请求的响应应对是经一个单独的TCP连接发送，该应用程序被称为使用非持续连接。
所有的请求及其响应经相同的TCP连接发送，该应用程序被称为使用持续连接。
HTTP可以使用非持续连接，可以使用非持续连接。在默认情况下，HTTP使用持续连接。

非持续状态HTTP连接

非持续状态下，从服务器向客户传送一个Web页面的步骤。

其中每个TCP连接在服务器发送一个对象后关闭。就是这个HTML里包括10个图片，那么这个TCP就是要搞11次，这11次都是不同的TCP连接。
在默认方式下，大部分浏览器打开5~10个并行的TCP连接，每条连接处理一个请求响应事务。如果你去设置最大并行连接数为1，那就这些TCP连接就会串行建立。
基于这个方式可以计算一下一个TCP传输所需要的时间
2*RTT+传输文件的时间

持续方式的HTTP连接

HTTP报文格式

HTTP报文有两种类型，分别是请求报文和响应报文。

HTTP请求报文格式

第一行是请求行：方法字段 + URL字段 + HTTP版本字段
后继的行是首部行
Host 指明对象所在的主机
User-agent 指明用户代理（浏览器类型）
connection ： close 就是上面的那个持续连接关闭
Accept-language ：fr 首部行表示用户想得到该对象的法语版本

通过wireshark抓包后，请求报文主要是这个部分。

HTTP响应报文格式

分为三个部分
初始状态行
首部行
实体体（这个是主要部分）


状态码

用户服务器状态：cookie

HTTP服务器是无状态的
但是为了Web站点有时候希望可以识别用户、限制用户的访问、把内容跟用户身份进行连接等。所以很多Web站点使用了cookie。

客户端在第一次发送请求时不带cookie，然后服务器给他分配一个cookie，并且自己保留
然后客户端保留自己的cookie，下次再访问的时候就带上这个cookie
可以把http无状态的协议变成有状态的协议
在请求报文中有一个cookie行
可以通过cookie值去关联一些行文（比如登录，避免每一次都登录）
cookie会带来隐私的一些不太好的保障，你的cookie会包含很多你的信息

关于Web缓存

Web缓存器也叫代理服务器，它是能够代表初始Web服务器来满足HTTP请求的网络实体。
可以设置，对某对象的浏览器请求首先被定向到该Web缓存器。
举个栗子

Web缓存器即是服务器，又是客户。
缓存器的作用就是大大减少对客户请求的响应时间。
就是人有趋同性，然后如果hit了，就会减少一些开销

关于延迟
改善用户响应时间，让他变小
土豪做法你就增带宽？（不知道听错了没）

本地访问：proxy有的
外部访问：向origin server访问
上面的这些有的没的都是为了去减小那个响应的时间，去让用户体验变好

基于http协议以外还有很多其他的协议

FTP

FTP文件传输协议
FTP是明文传输的
早期通常采用ftp下文件或者说分享文件，有个ftp服务器，然后通过ftp客户端上传、下载。现在用的少了。
21号端口

完成用户认证（即提供用户标识和口令）
完成身份认证后，客户端可以向服务器发一些指令，把当前目录的某个文件下载给我。然后服务器主动跟客户端20号端口建立数据连接。在这个数据连接上，把文件传给你。原来的命令依旧命令，但是传数据是另一个连接数据连接上进行的。

开始一个FTP会话时，客户端首先与FTP服务器21号端口建立控制的TCP连接。这个连接用于发送用户的标识和口令，还有一些命令。
当服务端从这个21端口的连接上收到了文件传输的命令后，就发起一个到客户端的TCP数据连接。在这个连接上传文件，传完了就关了。

关于FTP的命令和回答
USER username ：用于向服务器传送用户标识
PASS password ：用于向服务器发送用户口令

都是站在客户端的角度去说上载和下载
客户端向服务器传输东东叫上载
服务器向客户端发文件叫下载

email

常见的一种应用email
email包括几个主要组成部分：用户代理、服务器、简单邮件传输协议SMTP
电子邮件的用户代理，就是客户端软件什么outlook这种。
web应用的用户代理是浏览器
FTP的用户代理是FTP客户端软件

是你的软件跟网络啊什么去打交道，不是你本人去打交道。

邮件服务器是电子邮件体系结构的核心。
每个接收方都在邮件服务器上有一个邮箱，管理维护发送给它的报文。

用户代理通过邮件服务器发邮件，邮件放到邮件服务器的队列里
邮件服务器挨个取邮件，然后再根据地址发走

用户代理发到邮件服务器（推），邮件服务器发到目标邮件服务器（推），目标那个进行拉取（拉）前两跳是推，后一跳是拉

端口号 25 port
邮件所有都是ASCII码编码的范围
带来的一个问题就是，中文怎么办
所以就要编码、扩展。

邮件本身是有格式的
头部典型的信息 from to title cc这些东西

SMTP

SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器

关于SMTP的基本操作

SMTP如何把一个报文从发送邮件服务器传到接收邮件服务器
1、在发送邮件服务器上，客户SMTP在25号端口建立一个到接收邮件服务器SMTP的TCP连接
2、如果服务器没开机，就等会儿再连
3、成功连接后，服务器和客户端执行某些应用层的握手。在握手阶段，SMTP客户指定发送方的邮件地址（就是发的人）和接收方的邮件地址。
4、握手结束之后，SMTP客户发送这个报文投递到接收服务器。

客户从邮件服务器crepes.fr向邮件服务器hamburger.edu发送报文
发送的就是那个“”“Do you like ketchup？ How about pickles？”
那几个大写的HELO、MAIL FROM这些是命令
只有一个句点的行是向服务器表示该报文结束了。
CR表示回车 LF表示换行
可以用telnet连接看看，公司电脑不敢瞎搞，回去折腾折腾自己电脑试试。
搜索就搜如何telnet本地邮件服务器

比较一下HTTP和SMTP

应用层协议之DNS

参考：https://blog.csdn.net/crazymakercircle/article/details/120521694?

应用层协议好多，比如FTP、DNS、HTTP、telnet、SNMP
然后这里介绍一下 DNS 域名解析系统
这个不是直接给人用的，是一个被其他应用应用的应用
web会用，FTP也会，
DNS是一个基础性的系统

DNS提供域名到ip地址的转换
ip地址的作用一个是标识、一个是寻址
域名相比起IP地址非常容易记
DNS主要提供的就是域名到ip地址的自动转换
运行在UDP的53号端口
DNS是在应用层实现的

互联网的复杂性是体现在传输层以上的

DNS工作原理，怎么去实现的自动转换？

第一，命名

分层化命名域名
把每个分成


就像一颗倒着生长的树
这样重名的可能性就会大大减小

命名从树叶往树根走
域的域名就是从树枝往上走
从右往左看
比如百度
www(主机域名).baidu（二级域名）.com（顶级域名）

域和物理网络没得关系
他是逻辑上的

第二、解析

一台设备集中的解决域名解析是不可行的，不管从流量带宽都承担不起那么多的设备去访问
所以可以用分布式（就是不集中）
分布式数据库
顶级域知道二级域
二级域知道三级域
这样一层一层下来
上层区域知道下层区域往哪里走
就好像edu的，你要知道清华、北大这些学校的域名，嗯路径？
每个区域的权威服务器，都要维护一个服务器，我们也叫资源记录。以数据库资源记录的形式。

两种查询方法
递归查询，上一个不知道就再往上问
迭代查询，给路径，问根，根不知道去问某个顶级域，顶级域不知道给你个二级域，一路到最后的主机域

第三、维护

虽然是访问一个域名，但是具体分到哪个服务器是不确定的，这样还可以满足一定的负载均衡。

提高性能的方式：缓存

关于DNS的查询过程

顺带一提，向 DNS 服务器发送消息时，我们当然也需要知道 DNS 服务器的 IP 地址。
只不过这个 IP 地址是作为 TCP/IP 的一个设置项目事先设置好的，不需要再去查询了。

以上内容是大致的流程，就是我发送请求时，首先会去访问DNS根据域名获取ip，然后根据这个ip找对应的服务器去获取信息再返回。
但是DNS是怎么工作的呢，是怎么找到根据域名找到ip的，毕竟这个数据量是很大的，很多人都在查这个，而且DNS挂了之后是会直接影响到整个数据收发的。

网络类型模式之P2P

在C/S模式下，服务器的负担很重。挂掉了就大家就会访问不了。

P2P的可靠性比较高，你很难把他搞瘫掉
在某些会话上他是客户端，在某些会话（session）上他是服务器
比如QQ、钉钉
p2p的用户应用很容易扩展到上百万
比如探探
你不是从服务器，是从别的节点获取流量服务，是分布式的
就像节点进行相互服务

从性能上分析一下c/s模式和p2p模式的
c/s：上载是ui，下载是啥di（好像反了） 上载下载这些前面说了都是根据客户端为主体说的
所有的客户都是通过服务器获取服务
然后计算了所有客户端要在服务器上下一个文件时间的下限
（好像给了一个公式）真正的下载时间是大于等于这个下限
随着n的数量越来越大，xx可以忽略不计
然后根据那个公式，可以分析在服务器和客户端的数量不同时，瓶颈存在的地方不同
比如你服务器完全够够承担客户端，那么瓶颈是客户端的下载
如果客户端太多太多了，那么瓶颈就是服务器的上载

p2p：
好像又是一个公式，在算下限
他的问题就是，他的管理会比较难

p2p也分，结构化p2p和非结构化的p2p
非结构化p2p：p和p我们建立连接，然后你来我往通信有无，我和你之间就像有条边的关系。这种逻辑上的网络，我们叫覆盖网。
然后这些p p节点，还能继续构成更复杂的环、树的关系。

结构化p2p：
耐普四特（就是那个啥大几新生为了发mp3做的那个第一代？p2p系统）有集中化目录
也存在问题，目录服务器挂了怎么办，单点故障

完全分布式的：（我也不知道他是不是结构化的p2p）
一个例子 xxxx（一个英文名）
每个p节点都一样，构建一个欧沃累t（英文名）
怎么查，像所有的邻居发送查询，然后邻居再想他的所有邻居发送查询。这种叫泛洪。
拥有这个资源的节点，就返回这个目录
然后再像拥有这个资源的目录发出查询，然后获得资源
但是这个泛洪式的查询不可靠性也太大了，传者传者就很容易形成回路，隔了好久链路里还存在你有吗你有吗。解决办法可以有比如TTL，让中转节点记住，转过就不转了。
那怎么去加入和退出邻居节点，又是一堆规则和方式。
这些看起来好像是可以的，但是还是存在问题，完全分布式没有搞起来。

混合体：
就是有组长

描述信息
哈希？散列式？
哈希值是一个文件的唯一标识，就像个命名？

看一个例子：bt
p要加入到一个洪流当中，跟他们互通有无。就是我有了给大家，大家有了也给我。
加入洪流之后是怎么互通有无的呢？
我所具备的知识点和别人具备的知识点互通有无
如果我具备这个知识点就标注1，不具备就标注0，搞成了一堆bit map
然后通过泛洪，所有人就知道别人的拥有的知识点的情况。

位图?
p节点加入时，一开始没有资源，先搞几个，再去请求稀缺块。就像个吸血鬼慢慢得到文件？
然后获得完所有文件了，就看节点你在洪流里待着还是离开

（这个泛洪的过程，并没有太听懂，好逻辑啊）
每个节点从一开始什么都没有，然后根据一定的那种方式去获得信息（什么随机、稀缺、优化）

bt是一种非结构化的p2p

这个bt网络，怎么加入洪流呢
dai wai解决？
tracking server？？进行请求，分配列表？
啊别管我了我又没听懂，我只觉得好有道理，疯狂发呆。
我还是把书买了去看看吧

视频流化服务和CDN

如何像上百万级的用户提供视频业务呢

会遇到的问题：
每个节点他的上下载能力，他的很多乱七八糟的都不一样
然后就是数量级比较大

视频可以认为，是一个个的图像所构成的
现在的视频帧率是很高的，每秒种40帧甚至能到60帧
视频业务的特点就是，占的带宽非常大
音视频在网络上传输的时候一般都要进行压缩，纯原件对带宽的消耗太大了
ivs？高级视频编码
不同的设备解析度是不一样的，pc机和手机好像都是不一样的。

流化服务
你看电影的时候不是完全下下来看吗 no 这个就不是播放视频，是下载文件
流化就是一边下一边看，有个那个缓存
流化播放可以大幅度减少用户的等待时间
常用的一个协议desh？还是dash?
在http下的动画自适应技术
处理的时候可以处理成不同的解析度 什么360p 720p 1080p

dash可以解决不同网络端不同需求的问题

流化服务器质量提升

采用CDN的方法

CDN运营商部署了很多缓存节点

大概就是一些部署的模式，啊不想听，啊听不懂
中科蓝讯？做内容加速