应用层
软件
第二章节
传输层向应用层提供的服务:SocketAPI
传输层提供端口号,用于区分不同的进程
TCP和UDP都提供16位的端口号,65536个端口
socket就是整数
socket是在本机存储的,连接的对方并不知道
tcp_socket主键是四元组,代表着自己的IP 端口号和对方的IP 端口号,额外存连接状态信息
udp_socket主键是二元组,代表着自己的IP 端口号
数据安全性:SSL协议(应用层协议),在TCP之上
例如:HTTPS 就是使用了SSL协议
SSL也提供了SSL级别的Socket API
服务器的wait socket(listen一个端口):
来一个新的连接,再创建一个新的connect socket对应
HTTP应用层协议
HTTP1.0协议是无连接的,服务器发完数据,不维护连接状态,发一次就关连接。
HTTP1.1协议的默认方式:流水线方式,发送一个请求,在上一个请求没传完的情况下,继续发第二个请求。
HTTP1.1协议是有持久连接的,服务器发完一次数据,不关连接。
http本身是无状态协议,想要持续服务变成有状态协议,需要使用cookie机制
代理服务器:用户发来的请求,如果缓存里有,给目标服务器发HEAD请求,只要内容最后修改的时间,如果和本地缓存的时间一致,直接发给用户,否则当作缓存里没有;如果缓存里没有,给目标服务器发请求。
FTP协议
服务器主动和客户端21端口建立连接
FTP是有状态协议,控制连接需要一直存在
SMTP协议
用户代理
用户代理就是Email的客户端软件
帮用户把邮件发到邮件服务器的发送队列中,然后服务器再把它发走
用户代理需要从服务器拉取邮件信息
邮件服务器协议
客户端在25号端口接收
http是拉取的。smtp是推送的。
http一次传一个对象,带链接的需要额外再拉取。
smtp一次传多个对象,邮件里的图片等等
报文只能是ASCII码
中文字符怎么办?
多媒体数据、中文字符等需要通过base64编码
给服务器发邮件和服务器之间发邮件是用了SMTP协议
从服务器拉取邮件用POP3,IMAP.HTTP都可以
DNS协议
在网络边缘实现的,
互联网的复杂性主要在网络边缘
当一个DNS请求到达DNS服务器,DNS服务器可以选择一个特定的服务器IP地址返回(对于这个用户来说最优,一般是离得比较近的服务器)
域名划分是逻辑的,不是物理的
可以把同一个域下的域名分给天南海北的主机
把域的内部分为一个个区域,每个区域设置一个权威名字服务器
中间的DNS服务器获取到其他DNS服务器的RR值,会缓存下来,这个缓存的TTL就是有限值
缓存:为了效率
删除:为了一致性
NS:Name放子域的名字,Value放子域的权威服务器域名,这样才能往下找下面的子域
对于上层服务器来说,需要知道两个信息,子域的名字是什么,子域权威服务器的IP地址是什么
递归查询:从根服务器开始查找,一直找到目标域名的权威名字服务器,就拿到了
缺陷是,所有查询都要让根服务器去一层层查。负载大
迭代查询:根只负责给出下一跳的地址,本地DNS去 根给的顶级域,本地DNS再去 顶级域给的下面的域
P2P
非结构化P2P
Peer和Peer之间建立边,互通有无,是逻辑的网络,不是物理的网络
集中式目录
集中式目录:上线时在目录服务器上注册,自己是哪个节点有哪些资源
缺点:目录服务器挂了,版权风险
完全分布式
先建立初始邻居关系(Overlay):在安装软件的时候,同时给定了一些常在线的结点列表。然后ping这些结点,这些结点返回然后帮助ping这些结点的邻居,本机随机选择其中8-10个保存起来,建立联系(这里是一个主机加入P2P网络的方式)。
退出的时候:跟这8-10个结点说我要下线了。然后这些结点和他断开联系,再从网络结点中补充一个结点的联系。
泛洪:向所有邻居查询,邻居再帮你查询相邻的邻居
泛洪的缺点:一个查询停不下来,十天半个月还在网络里游荡
解决方法:设置TTL(有限泛洪),记忆化(已经发过的目标就不再发了或者知道自己收过这个查询再收到这个查询就不再处理)
Gnutella网络的缺点:技术问题没解决好,有人说在他上面什么也找不到。被迫开源。
混合体
实践例子
bitmap方式将文件分块:互相交换各自拥有的块。
新加入的结点用户,没有任何块,要先随机拿4块容易拿到的,再优先请求稀缺的块,这样之后才能和别人交换块。
优先向贡献多的目标提供服务。
torrent文件中包含:tracking server(负责给你分配peer列表,把你拉到洪流中)
DHT 结构化P2P
Peer和Peer之间构成有序的关系,比如环、树
用户IP地址做哈希,根据哈希排列出来一个环或者树
文件也做哈希,哈希排列后,把一段范围内的文件交给一个用户负责
其他用户需要这一段文件直接算哈希去找他
优点:不需要重复存这个文件的副本,每个有序Peer关系里有一个人有这个文件就可以
CDN协议
CBR
压缩出来的码率基本不变的
VBR
可变码率
把视频切成一块一块的,每块可以维持8-10秒的播放
告示文件(manifest):
- 是什么文件
- 描述信息
- 切成多少块
- 每块有多久
- 有多少个版本
- 每个版本的URL
下载哪个服务器的哪些块是客户端决定的。
CDN运营商:用大量的缓存结点为ICP给用户提供CDN服务
CDN部署:
- enter deep:建立Local ISP,自己分布的服务器通过私有网络连在一起
- bring home:把服务器部署在距离上游ISP附近的地方,虽然跳数多,但是在关键位置服务质量也好。
CDN服务:
- 第一种方法,用户先从源服务器获得manifest文件,从文件中知道附近的结点
- 第二种方法,域名解析的重定向
用户向源主机请求视频,源主机的DNS权威服务器发出重定向,让用户去找CDN权威服务器,CDN权威服务器告诉用户去找哪个CDN主机获取视频
socket
服务器先运行
创建一个socket,目的是返回一个(操作系统给的)整数
但是这个整数什么都不是
再把这个整数和本地的IP端口捆绑
这个叫做Welcome Socket
之后再调用socket API的另一个函数,accept
来接收远端进程,和他握手的关系
没有人连接的时候,函数阻塞
连接成功,返回一个新的socket值,叫Connection Socket
客户端默认有一个bind,调用connect,之后阻塞,直到服务器同意连接
结构体 sockaddr_in:服务器守候的IP地址和端口号
结构体 hostent:是域名解析的返回值
listen的作用,队列长度,每次accept从请求队列中拿出一个
UDP socket 只与本地IP和端口绑定
UDP 和 IP协议的协议数据单元都叫数据报,要分辨需结合上下文看
UDP socket的空间和TCP socket的空间不重合,所以可以用相同的整数代表。
传输层
TCP UDP协议
TCP是以流的形式传输,不保证内容的界限
需要在应用层做界限的检测
TCP修正的IP的无序、丢失等问题
TCP无法降低延迟
TCP能否提高IP的带宽
UDP是以数据报的形式传输
TCP 多路复用 解复用
很多的应用进程复用一个TCP实体
在源端复用,在目标端解复用
TCP、UDP实体只有各一个
发送方接收本机多个进程打算发送的报文,用socket套接字的数据封装,
可靠数据传输
只负责分发 rdt1.0
假设下面的channel有两个特性,不出错不丢失
rdt_send deliver_data是和上层的接口
udt_send udt_rcv是和下层的原语接口形式
出错校验 rdt2.0
ACK:接收到了
NAK:需要重发
rdt2.0里rdt的发送方有两个状态:等待上层调用发送,等待ACK/NAK
接收方只有一个状态:等待下层的调用
rdt2.0的缺点:校验了P的正确,但是ACK/NAK也有可能出错
2.1加入序号,当感觉接收方发送的数据不对的时候,把数据重新发一遍,接收方发现自己收到了两个相同的数据,就明白自己发的数据可能出错了,让发送方发下一个序号的数据,也就是ACK+1
这个特征叫做停止等待协议(发完停止,等待对方确认)
这里的ACK只用了1位,代表需要发老的Packet还是新的Packet
出错了直接回NAK,不用再检查序号了。
状态机三种状态:一号分组正确收到,等待一号分组来了0号,来了个错误的分组。
2.2没有NAK只有ACK,但是对ACK编号
等1的时候,收到错误的数据包,在2.1中是发送NAK,请求重传
在2.2中,发送ACK0,告诉我收到的是上一个数据包,下次给我传1
语义上是一样的。
出错校验和丢失校验 rdt3.0
2.X的缺点,发送方发出分组丢失,发送方等确认,接收方等新的分组,形成死锁
超时重传机制,设置比正常往返稍微多一点的时间,超时就认为分组丢了
发送方等待ACK1,但是收到ACK0
这时发送方不立即发送P1,而是等到超时了再通过超时重传发送P1
缺点:超时定时器设置不合理,还可以正常工作,但是带宽占用,超时交错一次,之后往返就会更加频繁
那么超时会不会导致数据错误呢?比如我发了一堆P0,全都在路上,接收方会不间断的收到P0(这条信道很慢),接收方收到第一个P0之后,返回ACK0,发送方接收到ACK0,发送P1,这时候信道切换了,走了一条极快的信道,直接在剩余的P0还没完全到达接收方的时候,P1先到了,这样接收方就会正确的接收P1,但是马上又会有之前的古老P0过来,接收方下一个接收了错误的P0
这就只能靠链路层和网络层的信道控制来实现了,保证这次通信的每一跳的中转网络结点都不变。
老师也提到了我这种问题,说比较大的延迟就相当于对数据重新排序了,这种情况也会被检查出来,这个以后再讲
另一个缺点是信道利用率太低,发出去一个packet很快,但是等待时间长。
利用率0.027%
滑动窗口协议
当发送窗口SW=1,接收窗口RW=1的