计算机网络是互连的,自治的计算机集合。
- 自治:计算机之间没有主从关系,一个计算机不能控制另一个计算机
- 互连:计算机之间要互连互通,通过通信链路,e.g. 光纤、无线、电缆
计算机通过交换网络连接位置远 数量大的计算机。
Internet:
网络把主机连接起来,而互连网(internet)是把多种不同的网络连接起来,因此互连网是网络的网络。而互联网(Internet)是全球范围的互连网。
网络协议(network protocol)
约定计算机网络中数据传输、交换的规则。协议规定交换信息的格式、意义、顺序、以及收到信息发生的动作。
网络协议的三要素:
- 语法(syntax) : 信息的格式,e.g.底层信息0101
- 语义(semantics): 信息的含义
- 时序(Timing): 交换信息的时间顺序
-
网络边缘
- 通过接入网络,或者物理介质连接网络
- 由主机构成,主机运行网络应用程序
- 主机之间的通信方式
- 客户/服务器类型:客户发送请求,服务器接收请求
- 对等应用模型 peep-peep/p2p:不区分客户服务器,每台主机平等
- e.g. QQ
-
网络核心:互连的路由器,或者转发设备,将网络边缘加入网络核心
Internet 结构:网络之网络
主机通过连接到ISP接入网络,不同国家有自己的ISP, ISP之间互连,从而任意主机之间可以互连
目的:如果任意两个主机之间希望通信,可以在两个主机之间建立直接连接。但这种方法建立了过多链路。可以通过讲主机与交换设备相连。交换设备与交换设备相连,从而达到互连。
数据交换的类型:
- 电路交换:电路交换用于电话通信系统,两个用户要通信之前需要建立一条专用的物理链路,并且在整个通信过程中始终占用该链路。由于通信的过程中不可能一直在使用传输线路,因此电路交换对线路的利用率很低,往往不到 10%。
- 报文交换:将一整条报文(信息)当做整体发送。
- 分组交换:将报文拆成一系列较小的数据包,对每个包补充头部信息(e.g.地址,组号),构成分组。源主机将一系列分组通过路由器转发至目的主机。目的主机等收到所有分组后,合成至一条消息。
- 分组交换可能会发生丢包和延迟
- 延迟可能是等待数据转发的传输延迟,或者数据在路由器中排队等待处理的延迟
- 丢包:路由器的缓存有限,如果缓存已满,但还有分组到达,到达分组会被丢弃
分组交换:链路可以并行传输数据,报文交换相当于串行传输。分组交换所需的传输时间段,路由器缓存低。
多路复用 (multiplexing): 把链路资源划分成片,并把每片资源分配给一个请求。
- 排队延迟:分组在路由器的输入队列和输出队列中排队等待的时间,取决于路由器的堵塞状态
- 处理延迟:主机或路由器收到分组时进行处理所需要的时间,例如分析首部、从分组中提取数据、进行差错检验或查找适当的路由等。
- 传输延迟:从传输数据的第一个比特开始,到最后以一比特结束需要的时间。$ delay = \frac{L(bits)}{R (bits/sec)}$ ,由分组长度和链路带宽决定
- 传播延迟:电磁波在信道中传播所需要花费的时间,电磁波传播的速度接近光速。
- 速率:又称比特率,单位时间内传输的信息量,常见单位:bps (bit/s), kb/s, Mb/s
- 带宽
- 通信领域里,信号的最高频率与最低频率之差,单位: 赫兹Hz
- 网络的带宽指数字信道能传输的最高速率,单位bps
- 时延带宽积: 传播时延 * 带宽。代表链路中能容纳的比特长度,当第一比特到达链路结尾时,链路中容纳多少比特
- 丢包率:丢包数 / 已发分组总数
- 吞吐量(throughput): 在发送端与接收端之间传送的数据速率,单位b/s
计算机网络使用分层结构,每层都遵循某些网络协议,实现本层功能。
上下层存在服务关系,上层使用下层服务,上层通过接口与下层进行交互。
OSI模型:由国际标准化组织ISO提出的分层网络模型。当时市场存在多个网络模型,ISO提出来一个统一的国际网络模型。
-
应用层:为特定应用程序提供数据传输服务,例如 HTTP、DNS 等协议。数据单位为报文。
-
表示层:处理信息的语法和语义问题
- 数据表示转化:源主机将数据转换为主机独立的编码
- 加密/解密
- 压缩/解压缩
-
会话层:负责连接中的会话管理。
- 对话同步:在数据中插入同步点。如果数据在传输过程中中断,下次可以从最近的同步点恢复。
-
传输层:负责从源进程到目的进程之间的传输。发送方在传输层将数据切割成段,在接收方进行重组。
- SAP寻址:传输层确保报文发送给正确进行, e.g. 端口号
- 端口到端口连接的建立、断开
-
网络层:负责将数组分组从源主机传输到目的主机。在网络层传输中跨越多个网络。
- 逻辑寻址:在信息头添加全局唯一的逻辑地址,比如ip地址。这个地址在传输中不变,物理寻址在传输过程中不断改变,模拟jump的过程。
- 路由:帮助路由器选择路径,最终抵达目的主机
-
数据链路层:负责(物理链路直接相连的)结点之间的数据传输,单位为帧。
网络层针对的还是主机之间的数据传输服务,而主机之间可以有很多链路,链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。
- 组帧(Framing): 将来自网络层的数据添加头部尾部信息
- 物理寻址:在帧头中增加发送/接受端的物理地址(MAC 地址)
- 流量控制:匹配发送端的发送速度和接收端的接受速度,避免发送速度过快,堆满缓存
- 访问控制:决定哪个设备拥有链路的访问使用权
- 组帧(Framing): 将来自网络层的数据添加头部尾部信息
-
物理层:实现比特在物理介质上的传输。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异,使数据链路层感觉不到这些差异。
- 接口特性:机械特性(接口的几何形状?)、电气特性(多大电压传输?)、功能特性(接口的引脚功能)、规程特性(接口的工作过程?哪个引脚先接受信号?)
- 比特编码:如何用信号的特征表示01
- 数据传输速率:物理层数据以多快速度传输
- 比特同步/时钟同步
- 传输模式:单工(单向通信)、半双工(交替双向 e.g.对讲机)、全双工
端到端层:上四层,这四层只在源主机和目的主机上进行处理。
数据从上至下进行数据封装。数据封装的目的是增加控制信息,比如地址,协议控制(优先级信息、安全控制)。
应用层协议包括:
- 消息类型:请求/响应
- 消息的语法:消息中有哪些字段
- 字段的语义:每个字段中消息的含义
网络层服务的需求:
- 数据可靠性:有些服务能够容忍一定的数据丢失,e.g. 网络电话,但有些服务要求100%的数据传输:文件传输
- 延迟:有些服务可以容忍高延迟,但有些应用要求低延迟
- 带宽:有些应用对网络带宽有要求,e.g. 网络视频,但有些应用可以适应任何带宽
进程间通信使用socket发送/接受消息。
进程寻址:使用ip地址定位主机。但同一主机可能同时有多个进程需要通信,利用ip地址+端口号标志不同进程。
HTTP使用TCP传输服务,连接流程是:
- 服务器在80端口等待客户请求
- 浏览器发送到服务器的TCP请求
- 服务器接收TCP连接
- 客户端与服务器交换信息
- 关闭TCP连接
HTTP是无状态协议,即服务器不维护客户端过去发送请求的消息。
根据每个链接传输对象的数量,HTTP连接分为两种类型:
- 非持久性连接:每个tcp连接最多传输一个对象,早期http协议是这种类型
- e.g. 假定用户在浏览器输入url www.someschool.edu/home.index (包括10个jpeg)
- 客户端向edu服务器的80端口发送tcp连接请求
- 服务器接收80端口的tcp请求
- 客户端发送http请求,请求对象为/home.index
- 服务器解析请求,发送响应消息给客户端
- 服务器关闭tcp连接
- 客户端解析响应信息,发现有10个指向jpeg对象的链接
- 客户端为每个对象,重复步骤1-5
- 缺点:操作系统需要给每个tcp资源开销资源
- e.g. 假定用户在浏览器输入url www.someschool.edu/home.index (包括10个jpeg)
- 持久性连接:每个tcp连接允许传输多个对象,http v1.1之后默认是这种类型
- 无流水的持久性连接:客户端收到前一个响应后才发送新的请求
- 带有流水机制的持久性连接:客户端只要遇到一个引用对象就发出请求,http1.1的默认选项
HTTP的消息格式:
-
请求消息 request
Get /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: mozilla/4.0 Connection: close
第一行是请求行,包括请求类型(Get/post) 及请求资源(URL), HTTP版本
第二行之后是头部信息。服务器根据不同浏览器,不同语言会采取不同操作。
-
响应消息 response
HTTP/1.1 200 OK Connection: close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3 Content-Length: 6981 Coneect-type: text/html data data
-
HTTP响应的状态代码
200 -> OK
301 -> Move permanently
400 -> Bad request
404 -> Not found
-
- 用户输入url
- 浏览器查找域名的IP地址 域名解析(DNS解析)
- 找到IP地址后,建立TCP三次握手 ,与目标服务器建立连接
- 握手成功后,通过规定的协议(http),浏览器向目标主机发送http请求,请求数据包
- 服务器处理收到的请求,将数据返回至浏览器
- 浏览器收到HTTP响应报文
- 关闭连接 浏览器解析文档
- 读取页面内容,浏览器渲染,解析html源码
- 生成Dom树、解析css样式、js交互
Http 1.0
- 无状态:服务器不跟踪不记录请求过的状态
- 无连接:浏览器每次请求都需要建立tcp连接
http1.1
- 长连接:新增Connection字段,可以设置keep-alive值保持连接不断开
Http 2.0
多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
HTTPS(Hypertext Transfer Protocol Secure)协议的基本流程是
- 客户端向服务器端索要并验证公钥。
- 双方协商生成"对话密钥"。
- 双方采用"对话密钥"进行加密通信。
前两步的具体操作为:
-
客户端发出请求
一个客户端生成的随机数,支持的加密方法,比如RSA公钥加密。
-
服务器回应
- 一个服务器生成的随机数,稍后用于生成"对话密钥"
- 确认使用的加密方法,比如RSA公钥加密。
- 服务器证书
-
客户端回应
首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告。
一个随机数,该随机数用服务器公钥加密。在整个握手阶段出现了三个随机数,并且客户端和服务器同时掌握,双方用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。
-
服务器的最后回应
然后整个握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用"会话密钥"对称加密内容。
由于http协议是无状态的,不保留客户发送请求的历史记录。但有些网站(例如电商)需要保留客户的会话状态及在线信息,提出了cookie技术。它是为了辨别用户身份,进行session追踪,从而存储在客户端本地的数据。
Cookie的组件
- http响应消息的cookie头部行
- http请求消息的cookie头部行
- 保存着客户端上的cookie文件,由浏览器管理
- 服务器端的数据库
Cookie使用流程:
代理服务器在不访问服务器的情况下响应客户端的HTTP请求。代理服务器可以缩短客户请求的响应时间,并实现有效的内容分发。
过程:
如何保证缓存服务器的对象和服务器上一致?
http请求的数据项中包括if-modified-since
。缓存向web服务器发送所持有对象版本的http请求,如果服务器有更新版本,则返回新对象;否则返回304.
Email应用由3部分组成:邮件客户端、邮件服务器以及邮件协议。
Email通过MIME多媒体邮件扩展,支持传输多媒体文件。MIME在STMP协议头部行中增加额外的信息,指明多媒体数据类型及编码方法。
邮件协议:
- SMTP协议:使用TCP发送email消息。
- POP3协议:邮件访问协议。POP3 协议支持多个模式:
- 下载并删除:用户从服务器上读取了邮件,就把该邮件删除
- 下载并保持:不同客户端都可以保存历史邮件
- IMAP协议:更复杂的邮件访问协议
DNS (Domain Name System) 解决了IP地址与网络域名相互转换的问题。DNS还可以实现负载均衡。当客户端向DNS请求ip地址时,DNS 存储多个域名-ip地址的映射,并轮流返回ip地址。
DNS 是分布式数据库,每个结点只存储部分数据。
DNS 服务器是层次式,分为根域名、顶级域名、二级域名
- 根域名服务器:如果本地域名解析服务无法解析 IP, 访问根域名服务器
- 顶级域名服务器:负责解析com, org, net, edu等顶级域名和cn, uk, fr等的国家域名
- 本地域名服务器:每个ISP默认提供一个本地域名服务器。
例子:客户查询www.amazon.com 的 IP
- 客户端查询根服务器,找到com域名解析服务器 IP
- 查询 com 服务器,找到amazon.com 域名解析服务器 IP
- 查询 amazon.com 服务器,返回 www.amazon.com 的 IP
DNS 服务器会缓存 IP 地址与域名之间的映射,一段时间后更新缓存,获得最新IP。
如何注册域名?
-
向域名管理机构注册域名 e.g. network.com
-
域名管理机构向顶级域名服务器插入两条记录
(network.com, dns1.network.com) // 域名, dns解析服务器 (dns1.network.com, 212.212.212.1) // dns解析服务器,ip
TCP:
- 客户机/服务器间需要建立连接
- 可靠的传输,保证数据不丢失
User data protocol(UDP)是无连接的,尽可能为用户提供交付服务。这意味着数据可能丢失,也可能不按序到达。
无连接 意思是UDP发送方和接收方之间不需要握手。
UDP的优点是:
- 因为发送方和接收方不需要建立连接,所以UDP传输的延迟低。
- 需要的消息头部空间小,TCP 20 个字节,UDP 8个byte
- UDP没有拥塞控制,上层应用可以完全掌控数据的发送时间和速率
基于上述特点,UDP常用于流媒体应用。流媒体应用可以容忍数据丢失,并且对传输速度有高要求。UDP还用于DNS和SNMP服务。
UDP的报文格式:
整个UDP头部包括:源端口号(2 byte)、目的端口号(2 byte)、报文长度(2 byte)、以及校验和。
校验和 (checksum) 用来检测UDP段是否在传输过程中发生错误,比如0变成1,1变成0.
- 发送方
- 把UDP首部和数据段看成是很多16位的字符串
- 用二进制求和计算这些16位字符串的和。如果有进位,取多余的进位加到最低位。
- 最后把计算结果按位取反,得到校验和
- 接收方
- 把收到的UDP头部和数据段计算校验和
- 把它和收到的校验和比较。如果不相等,说明传输中有错误;如果相等,说明没有检测出错误,但有可能有错误。
因为传输层的下一层 网络层提供的是不可靠的传输协议,需要在传输层实现可靠的数据传输协议,又称Rdt.
Rdt 1.0: 可靠信道上的可靠数据传输
这个协议假设底层信道完全可靠,即不会发生错误、不会丢失、不会乱序。
发送方和接受方的状态机 (finite state machine)相互独立。
- 发送方:状态:等待上层调用
- 接收方:等待下层调用
Rdt 2.0:产生位错误的信道
在这个信道上分组不会丢失、不会乱序,只可能产生位错误。
接收方:1)判断分组有没有错误 2)如果有错误,通知发送方
如何从错误中恢复:
- 确认机制(Acknowledgement, ACK):接收方通知发送方正确接收
- NAK: 分组有错误,发送方收到NAK后重传分组
Rdt 2.0的缺陷:无法判断ACK/NAK是否发生错误。
有几种解决方案:
- 为ACK/NAK添加校验和
- 如果ACK/NAK坏掉,发送方重传。但可能导致消息(分组)重复发送
Rdt 2.1: 针对ACK/NAK破坏
针对于Rdt 2.0的缺陷,可以通过重复发送ACK/NAK消息解决。如果接收方收到错误的ACK消息,可以要求发送方重新发送数据。但引出了一个新的问题:数据重复发送。
针对重复分组问题,可以通过序列号改进。发送方给每个分组添加一个序列号,接收方丢弃相同序列号的重复分组。
Rdt 2.2: 无NAK消息
通过在ACK消息中加入最新收到的分组的序列号。如果发送方收到和之前重复的ACK, 说明最新分组没有发送成功,需要重传。
Rdt 3.0: 信道可能发生两种错误:位错误,或丢失分组
如何处理丢失分组:设置合理等待时间(timeout)。如果发送方在一定时间内没有收到ACK, 则重传。
但这样引入一个新问题,如何设置合理的时间?如果ACK只是延迟,不需要重传?
流水线机制:为提供链路利用率,允许发送方在收到ACK之前连续发送多个分组。发送方/接收方需要更大的存储空间来缓存分组。
为了实现流水线机制,需要实现滑动窗口协议。窗口代表允许使用的序列号范围,窗口的尺寸为N,表示有N个等待确认的消息。窗口左边(绿色部分)表示已经使用过的序列号。
Go-back-N 协议 是一种滑动窗口协议。
ACK(n): 确认到序列号n (包括n) 的分组已经被接受。
Timeout(n): 发送方重传序列号>=n, 还没有收到ACK的所有分组。
接收方设置一个expect num, 如果收到的分组不是expect num, 则丢弃。
Selective repeat 协议 是另一种滑动窗口协议。
接收方设置缓存机制,对每个分组单独确认。这样发送方之重传没收到ACK的分组,相比于GobackN重传没收到ACK的所有分组,效率更高。
实现SR协议,需要在发送方和接收方都维持一个滑动窗口。
TCP是面向连接的传输协议。在发送数据前双方必须建立端到端的连接。TCP使用流水线机制,提升传输性能。
序列号:代表segment中第一个字节的编号,而不是segment中的编号。e.g. 假设有1k bit长度的数据,分成两个segment进行传输,那么第二条报文的序列号是501。在建立TCP连接时,序列号由双方随机生成。
确认号:是期望收到对方下一个报文的第一个数据字节的序号
确认ACK,仅当ACK=1时,确认号字段才有效。
SYN: 在连接建立时用来同步序号。在连接建立时用来同步序号。当SYN=1,ACK=0,表明是连接请求报文,SYN = 1 发起一个新连接
如果在规定时间内一方没有收到期待消息,则发送方会重传数据。那么TCP如何设置定时器的超时时间?这个时间一定要大于RTT (round trip time),也就是发送端从发送数据开始,到收到来自接收端的确认数据的时间。
因为RTT随着网络状态的变化而变化。测量RTT, 可以采用多次测量取平均值的方法。同时使用指数加权方法,sampleRTT
表示新测量结果,estimatedRTT
表示 RTT 的估计值。不断利用新加权结果更新估计值。
EstimatedRTT = (1-alpha) * EstimatedRTT + alpha * SampleRTT
在 TCP 协议中发送方一共有3种操作:
-
从应用层接受数据:
创建segment, 生成序列号,开启计时器,设置超时时间
-
超时
重传引起超时的segment, 重启定时器
-
收到ACK
如果收到之前没有被确认的segment, 更新窗口
假设 A 为客户端,B为服务器。
- A 向 B 发送连接请求,SYN=1(希望建立连接), seq (序列号)=x
- B 收到连接请求。如果 B 同意建立连接,则向 A 发送确认连接的消息。SYN=1, ACK=1, seq=y, ACKnum (确认号)=x+1
- A 收到 B 的连接请求后,还需向 B 发出确认。ACK=1,ACKnum=y+1,seq = x+1。
三次握手的原因:
第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留,那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后,就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器,如果不进行三次握手,那么服务器就会打开两个连接。如果有第三次握手,客户端会忽略服务器之后发送的对滞留连接请求的连接确认,不进行第三次握手,因此就不会再次打开连接。
https://www.cnblogs.com/Andya/p/13291686.html
-
A 发送连接释放报文,FIN=1。
-
B 收到之后发出确认,此时 TCP 属于半关闭状态,B 能向 A 发送数据但是 A 不能向 B 发送数据。
你好,我没有数据要发给你了,但是如果你Server端还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据
-
当 B 不再需要连接时,发送连接释放报文,FIN=1。
-
A 收到后发出确认,进入 TIME-WAIT 状态,等待 2 MSL(最大报文存活时间)后释放连接。
-
B 收到 A 的确认后释放连接。
为了保证客户端发送的最后一个ACK报文段能够到达服务器。
- 第一次挥手:客户端A的应用进程先向服务端TCP发出连接释放报文段
(FIN=1,序号seq=u)
,并停止再发送数据,主动关闭TCP连接,进入FIN-WAIT-1(终止等待1)状态,等待服务端B的确认。 - 第二次挥手:服务端B收到连接释放报文段后即发出确认报文段
(ACK=1,确认号ack=u+1,序号seq=v)
,服务端B进入CLOSE-WAIT(关闭等待)状态,此时的TCP处于半关闭状态。A收到B的确认后,进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。 - 第三次挥手:服务端B没有要向客户端A发出的数据,B发出连接释放报文段
(FIN=1,ACK=1,序号seq=w,确认号ack=u+1)
,B进入LAST-ACK(最后确认)状态,等待A的确认。 - 第四次挥手:客户端A收到服务端B的连接释放报文段后,对此发出确认报文段
(ACK=1,seq=u+1,ack=w+1)
,A进入TIME-WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,A才进入CLOSED状态。
四次挥手的原因
客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。
TIME_WAIT
客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:
- 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文,那么就会重新发送连接释放请求报文,A 等待一段时间就是为了处理这种情况的发生。
- 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文。