计算机网络
第一章：计算机网络概述
1.1什么是Internet
构成角度
网络是一个大概念，比如人和人之间的人际关系也算网络。
计算机网络
节点：主机及其上运行的应用程序（主机节点） / 路由器，交换机等网络交换设备（数据交换节点）
边：通信链路
接入网链路：主机连接到互联网的链路 （主机跟数据交换节点之间的）
主干链路：路由器间的链路 （数据交换节点之间的）
计算设备
主机 = 端系统
运行网络应用程序
通信链路
光纤，同轴电缆，无线电，卫星
分组交换设备
用来转发分组，路由器和交换机
协议
定义了在两个或多个通信实体之间交换的报文格式和次序，以及在报文传输和/或接收或其他时间方面所采取的动作
服务角度
分布式应用(网络存在的理由)以及为分布式应用提供服务的基础设施
1.2 网络边缘
==网络边缘是网络存在的意义==
==网络边缘通过介质接入和网络核心连接==
==网络核心==：相互之间的配合进行从远主机到目标主机数据的发送和接收
1.3 网络核心
网络核心：路由器的网状网络
==基本问题==：数据怎样通过网络进行传输
电路交换：为每个呼叫预留一条专有电路：如电话网
端到端的资源被分配给从源端到目标端的呼叫“call”
在网络核心中为两者建立独享的信令。
独享资源：每个呼叫一旦建立起来就能够保证性能，如果呼叫没有数据发送（接通了没说话），被分配的资源就会被浪费。通常被传统电话网络采用（固话）。
网络资源（如带宽被分为片）：频分，时分，波分。
每条链路的速率：按时分的意思是该链路只能被分到其中一个时间片。所以要除以24.
电路交换不适合计算机之间的通信
- 连接建立时间长：比如两个主机，建立连接假设500ms，但真正传输用了1ms
- 计算机之间的通信有突发性：比如微信聊天打字，也不是一直在聊天，是突发性的，如果占用连接，是独享的，不能被其他人使用，从而浪费资源。
- 可靠性不高：需要维护很多piece到piece，如果宕机，全完了
分组交换：存储转发
==以分组为单位存储-转发==
网络带宽资源不再分为一个个片，传输时使用全部带宽
主机之间传输的数据被分为一个个分组
==资源共享，按需使用==
在转发之前，节点必须收到整个分组
但是延迟比线路交换要大，同时还有排队时间，因为资源共享了，有可能你要传输前已经有别的在传输，还需要排队。
两个时间的浪费换取到的资源共享。
==排队延迟和丢失==
如果到大速率>链路输出速率
分组将会排队，等待前面的传输
如果路由器缓存用完了，分组将会抛弃（一个队列如果排满了，再进来的就会被抛弃）
网络核心的关键作用
==路由==：决定分组采用的源到目标的路径（通过路由算法）
==转发==：将分组从路由器的输入链路转移到输出链路
分组交换按照有无网络层的连接分为：数据报网络和虚电路网络
数据报工作原理
在通信之前，无须建立连接，有数据就传输
每一个分组都独立路由，携带了完整地址。
一个数据也许到同一个目标b，但走的路径不同（路由表在变），可能会失序
路由器根据分组携带的目标地址进行路由
虚电路工作原理
主机之间通信之前会建立虚电路
虚电路是靠信令建立起来的。
1.4分组延时，丢失和吞吐量
分组丢失和延时如何发生的
分组到达链路的速率超过了链路输出的能力，就会分组延时
可用的缓冲区有限（队列有限），满了再过来就丢失了。分组丢失
四种分组延时
1.节点处理延迟
检查分组首部和决定将分组导向何处（查路由表）
2.排队延时
取决于流量强度
流量强度 = La/R
3.传输延时
R=链路带宽（bps）
L=分组长度（bits）
将分组发送到链路上的时间=L/R
4.传播延时（发送出去每一个bit后在链路上消耗的时间）
d=物理链路长度
s=传播速度
传播延时=d/s
分组丢失
链路的队列缓冲区容量有限
丢失的分组，如果这层链路是可靠的，由上一层重传，如果这条链路不可靠，由源主机重传，但如果源主机使用UDP，丢就丢了。
吞吐量
在源端和目标端之间传输的速率（数据量/单位时间）
1.5 协议层次和服务模型
==层次化方式实现复杂网络功能==
- 将网络复杂的功能分层功能明确的层次，每一层实现了其中一个或一组的功能，功能中有其上层可以使用的功能：服务
- 本层协议实体相互交互执行本层的协议动作，目的是实现本层功能，通过接口为上层提供更好的服务。
- 在实行本层协议的时候，直接利用了下层所提供的服务
- 本层的服务：借助下层服务实现的本层协议实体之间交互带来的新功能（上层可以利用的）+更下层所提供的服务
==服务和服务访问点==
服务
低层实体向上层实体提供它们之间通信的能力
有服务用户和服务提供者，比如说服务提供者TCP可以提供给用户FTP或者web应用
原语
上层使用下层服务的形式，高层使用底层提供的服务，以及低层向高层提供服务都是通过服务访问原语来进行交互的—-形式
（比如顺丰可以给用户提供寄件，送件好多种服务，以不同的形式）
服务访问点SAP
使用下层提供的服务通过层间的接口—-低点：
例子：邮箱
地址：下层的一个实体支撑着上层的多个实体，SAP有标志不同上层实体的作用
==服务的类型==
面向连接的服务
面向连接服务通信的过程：建立连接，通信，拆除连接。
适用范围：大的数据块的传输
特点：保序
无连接服务
两个对等层实体在通信前不需要建立一个连接，不预留资源，不需要通信双方都是活跃。（例：寄信）
特点：不可靠，可能失序，可能重复
适合传送零星数据。
==服务和协议==
服务：低层实体向上层实体提供它们之间的通信的能力，是通过原语来操作的，垂直。
协议：对等层实体之间在相互通信过程中，需要遵循的规则的集合，水平。
本层协议的实现要靠下层提供的服务来实现
本层实体通过协议为上层提供更高级的服务
应用层：网络应用 FTP SMTP HTTP
传输层：主机之间的数据传输 在网络层提供的端到端通信基础上，细分为进程到进程，将不可靠的通信变成可靠的通信 TCP UDP
网络层：为数据报从源到目的选择路由 |主机主机之间的通信，端到端通信，不可靠 IP （用来转发）,路由协议
链路层：相邻两点之间以帧为单位的传输。
物理层： 相邻两点之间电磁波的承载。 p2p。把链路层传下来的bit传给对等层。
==封装解封装==
在源头要进行封装，把每一层的信息都封装，最后交给物理层去进行传输，在目标端要解封装最后给应用层传递message。
中途遇到链路层交换机就二层解封装，遇到路由器就三层解封装。（路由器：物理层解封装，给链路层传递帧，然后给网络层传递IP和路由，决定往哪个网口去传输，然后再封装，在传输）
==各层次的协议数据单元==
应用层：报文（message）
传输层：报文段：TCP段，UDP数据报
网络层：分组packet（如果是无连接方式：数据报）
数据链路层：帧（frame）
物理层：位（bit）
1.6历史
第二章：应用层
2.1应用层原理
可能的应用架构
客户-服务器模式 cs
对等模式 P2P
混合体
cs
服务器：
- 一直运行
- 固定的IP地址和周知的端口号
- 扩展性： 数据中心进行扩展，扩展性差
客户端：
- 主动与服务器通信
- 间歇性连接
- 不直接与其他客户端通信
P2P
在某个session上，我是客户端。在另一个session上，我是服务器。
- 没有一直运行的服务器
- 任意端系统之间可以进行通信
- 每一个节点即是客户端又是服务器
- 自扩展性，新节点带来新的服务能力量，当然也带来新的服务请求
难以管理：某个节点有时候会上线有时候会下线，上线时才能提供该节点的服务，所以需要监控节点上线下线。
混合体
比如说迅雷。
目录查询是集中式，文件分发是P2P。
当你查找一个文件，你是在集中的大目录下查询。查询到之后，谁有这个文件，你就跟谁P2P，同时你也有了这个文件，
这种模式，不怕用户多，用户越多，文件分发的能力越强。
进程通信
网络应用想跑起来，应用层需要做什么？
需要提供进程之间的通信，互相交换message。这样网络之间互相通信，就能跑起来。
分布式进程通信要解决的问题
问题1： 进程标示和寻址问题（服务用户）
标示自己 唯一 寻址：能够找到
问题2： 应用用传输层的服务交换报文，传输层的服务形式是怎么样的？
位置：层间界面的SAP （TCP/IP：socket）
形式：应用程序接口API （TCP/IP：socket API）
问题3： 如何使用传输层提供的服务，实现进程之间的报文交换
定义应用层协议：报文格式，解释，时序
编制程序，借助操作系统提供的API。
问题1：对进程进行编址
在哪个终端设备，ip是什么
你在终端系统上，你在UDP/TCP跑？
好多应用进程，你在哪个端口
任何两个应用进程之间的通信，都可以用端节点（ip和端口）来进行。
问题2：传输层提供的服务-需要穿过层间的信息
层间接口必须携带的信息：
要传输的报文（对本层来说：SDU）
传给谁（Ip Port）
谁传的 （Ip Port）
如果Socket API每次传输报文，都携带如此多的信息，太繁琐。
所以用一个整数组，用代号标示通信的双方或者单方：socket
就像操作系统打开文件返回的句柄一样。在c语言中你要操作一个文件，是操作系统返回的句柄，而不是操作文件名。
TCP scoket：
可以用一个整数表示两个应用实体之间的通信关系，本地标示
穿过层间接口的信息量最小
对于使用TCP的应用而言，套接字是4元组的一个具有本地意义的标示，只有你自己的应用层和传输层知道，是他们之间的一个约定。
4元组：（源IP，源port，目标IP，目标port）
UDP socket
同样是本IP.本端口
两个进程之间的通信需要之前无需建立连接。
问题3：如何使用传输层提供的服务实现应用
应用层协议定义了：
运行在不同端系统上的应用进程如何相互交换报文
应用层需要传输层提供的服务？
数据丢失率
延迟：电话就很在意延迟
吞吐
安全性
Internet传输层提供的服务
TCP:
- 可靠
- 流量控制：发送方不会淹没接受方
- 拥塞控制：当网络出现拥塞时，能抑制发送方
- 不能提供：时间保障，最小吞吐保证和安全
- 面向连接：要求客户端和服务器之间建立连接。
UDP：
- 不可靠
- 不提供其他的
那么为什么要有UDP：
- 不需要建立连接，简单
- 不做可靠的工作，简单好做，不用那么繁琐的过程。
- 没有流量控制和拥塞控制，注入很快
email TCP
Web TCP
文件传输 TCP
流媒体 TCP/UDP
INtenet网络 TCP/UDP
安全性
TCP/UDP没有加密
SSL：
在TCP上面实现，SSL在应用层。
应用层采用SSL库,SSL库使用TCP通信
2.2 Web和HTTP
==一些术语==
- Web页：由一些对象组成
- 对象可以是HTML文件，JPEG图像，Java小程序，声音剪辑文件等
- Web页含有一个基本的HTML文件，该基本HTML文件又包括若干对象的引用（链接）
- 通过URL对每个对象进行引用
- URL格式：
Prot：//user:psw@www.someSchool.edu/someDept/pic.gif:port
协议名 用户 口令 主机名 路径名 端口
==HTTP概况==
HTTP：超文本传输协议
HTTP使用TCP：
- 客户发起一个与服务器的TCP连接，端口号为80
- 服务器接受客户的TCP连接
- 在浏览器（HTTP客户端）与Web服务器（HTTP服务器server）交换HTTP报文（应用层协议报文）
- TCP连接关闭
HTTP是无状态的 服务器并不维护关于客户的任何信息
维护状态的协议很复杂！
必须维护历史信息（状态）
如果服务器/客户端死机，它们的状态信息可能不一致，二者的信息必须是一致。
无状态的服务器能够支持更多的客户端
==非持久HTTP==
客户端发送Tcp连接请求
服务器发送连接建立确认
客户端发送请求报文
服务器解析文件，拿出客户端想要的，然后封装为相应报文发给客户端
HTTP关闭TCP连接
==持久HTTP==
非持久HTTP的缺点：
- 每个对象要2个RTT
- 操作系统必须为每个TCP连接分配资源
- 浏览器通常打开并行TCP连接，以获取引用对象
持久HTTP
- 服务器在发送响应后，仍保持TCP连接
- 在相同客户端和服务器之间的后续请求和相应报文通过相同的连接进行传送
- 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求
- 分为非流水方式的和流水方式的
非流水方式的持久HTTP：
- 客户端只能在收到前一个响应后才能发出新的请求
- 每个引用对象花费一个RTT
流水方式的持久HTTP：
- HTTP/1.1的默认方式
- 客户端遇到一个引用对象就立即产生一个请求
- 所哟引用对象只花费一个RTT是可能的
==HTTP请求报文==
两种类型的HTTP报文：请求，响应
HTTP请求报文：
ASCII（人能阅读）
==提交表单输入==
Post方式：包含在实体主体（entity body）中的输入被提交到服务器
URL方式：方法：GET 输入通过请求行的URL字段上载
方法类型
HTTP/1.0 GET POST HEAD
HTTP/1.1 GET POST HEAD PUT:将实体主体中的文件上载到URL字段规定的路径 DELETE：删除URL字段规定的文件
HTTP响应状态码
200 OK
请求成功，请求对象包含在响应报文的后续部分
301 Moved Permanently
请求的对象已经被永久转移了：新的URL在响应报文的Location：首部行中指定
400 Bad Request
一个通用的差错代码，表示该请求不能被服务器解读
404 Not Found
请求的文档在该服务上没有找到
505 HTTP Version Not Supported
==用户-服务器状态：cookies==
大多数主要的门户网站使用cookies
4个组成部分
- 在HTTP响应报文中有一个cookie的首部行
- 在HTTP请求报文含有一个cookie的首部行
- 在用户端系统中保留有一个cookie文件，由用户的浏览器管理
- 在Web站点有一个后端数据库
cookies能带来什么：
- 用户验证 ：登陆过就不用登陆了
- 购物车
- 推荐
- 用户状态
cookies与隐私
cookies允许站点知道许多关于用户的信息，使用重定向和cookie的搜索引擎还能知道用户更多的信息
==Web缓存（代理服务器）==
目标：不访问原始服务器，就满足客户的请求
用户设置浏览器：通过缓存访问web
浏览器将所有HTTP请求发给缓存
在缓存中的对象：缓存直接返回对象
如对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端
为什么使用web缓存？
- 降低客户端的请求响应时间
- 可以大大减少一个机构内部网络与Internent接入链路上的流量
- 互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容
条件GET方法
目标：如果缓存器中的对象拷贝是最新的，就不要发送对象
缓存器：在HTTP请求中指定缓存拷贝的日期
服务器：如何缓存拷贝陈旧，则响应报文没包含对象
2.3 FTP
==文件传输协议==
向远程主机上传输文件或从远程主机接收文件
客户/服务器模式
客户端：发起传输的一方
服务器：远程主机
ftp服务器：port21
==控制连接与数据连接分开==
- FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议
- 客户端通过控制连接获取身份确认
- 客户端通过控制连接发送命令浏览远程目录
- 收到一个文件传输命令时，服务器打开一个到客户端的数据连接
- 一个文件传输完成后，服务器关闭连接
- 服务器打开第二个TCP数据连接用来传输另一个文件
- FTP服务器维护用户的状态信息：当前路径，用户账户与控制连接对应（有状态的协议，与http不同，http需要携带cookies）
命令的传输和响应和数据的传输分别在两个连接上进行。
2.4 Email
3个重要组成部分
- 用户代理
- 邮件服务器
- 简单邮件传输协议：SMTP（发送协议） 邮件访问协议：POP3 IMAP HTTP
用户代理
又名“邮件阅读器”
通过用户代理软件访问电子邮件应用。（web应用的用户代理是浏览器）
邮件服务器
守护在25号端口的服务器
作用：
用户代理发给邮件服务器，邮件服务器放入队列，邮件服务器一个一个发走，邮件服务器收到后，放到用户相应的邮箱中。然后用户再用用户代理，把别人发到邮箱中的邮件拉取过来。
EMail：SMTP
使用TCP在客户端和服务器之间传送报文，端口号为25
直接传输：从发送方服务器到接收方服务器
传输的3个阶段
- 握手
- 传输报文
- 关闭
命令/响应交互
- 命令：ASCII文本
- 响应：状态码和状态信息
报文必须为7位ASCII码
为什么要有队列，而不是直接发送？
缓解发送能力和接受能力的差异，当接受量大时，让其排队，平缓一点。
SMTP
SMTP使用持久连接：建立连接后一块发很多邮件
HTTP：拉 SMTP：推
邮件报文格式
首部行：
To：
From：
主体：
报文，ASCII字符
MIME：多媒体邮件扩展
base64：把若干个不在ASCII字符里的字节变成若干更长的在ASCII范围里的字符
POP3
用户确认阶段：
- 客户端命令
- user：申明用户名
- pass：口令
- 服务器响应：
- ok
- err
事物处理阶段
- List：报文号列表
- retr：根据报文号检索报文
- quit
2.5 DNS
不是给人用的应用，是给其他应用所使用。域名到ip地址的转换（web会用）
==DNS的必要性==
- IP地址标识主机、路由器
- 但IP地址不好记忆，不便人类使用
- 存在着“字符串” —— ip地址转换的必要性
- 由DNS负责转换成为二进制的网络地址
==DNS系统需要解决的问题==
- 问题1：如何命名设备
- 解决一个平面命名重名问题：层次化命名
- 问题2：如何完成名字到IP地址的转换
- 分布式的数据库维护和响应名字查询
- 问题3：如何维护：增加或者删除一个域，需要在域名系统中做哪些工作
==DNS主要思路==
- 分层的，基于域的命名机制
- 若干分布式的数据库完成名字到IP地址的转换
- 运行在UDP之上端口号为53的应用服务（UDP不需要握手，适合DNS这种）
- 核心的Internet功能，但以应用层协议实现（在网络边缘处理复杂性（端系统））
==DNS主要目的==
- 实现主机名-IP地址的转换
- 主机别名到规范名字的转换
- 邮件服务器别名到邮件服务器的正规名字的转换
- 负载均衡（分配不同的服务器为不同用户访问所服务）
工作过程就是先把别名转换为正规的名字，然后再转换为ip，再进行工作。
==DNS域名结构==
- DNS采用层次树状结构的命名方法
- Internet根被划为几百个顶级域
- 通用的：.com .edu .gov .int .mil .net .org
- 国家的：.cn .us .nl .jp
- 每个域下面可 划分为若干子域
- 树叶是主机
DNS有13个根名字服务器：防止只有一个的话宕机就无法查找。
==域名的管理==
树根该知道一级域有哪些，一级域知道二级域有哪些，依次层次化树状的就都能找到了。
一个域管理其下的子域。
域与物理网络无关，域的划分是逻辑的，不是物理上的。
==区域==
区域的划分有区域管理者自己决定
将DNS名字命名空间划分为互不相交的区域，每个区域都是树的一部分。
名字服务器：
- 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息
- 名字服务器允许被放置在区域之外，以保证可靠性
==区域名字服务器维护资源记录==
资源记录
作用：维护 域名-ip地址的映射关系
位置：Name Server的分布式数据库中
RR格式
Domain_name：域名
Ttl：time to live：生存时间（默认2天）
1 | 比如说 |
Class类别：对于Internet，值为IN
Value值：可以是数字，域名或ASCII串
Type类别：资源记录的类型
==递归查询==
比如北大的要想知道清华的Mapping，递归查询，先问13个根，再问一级域，二级域，直到清华域，清华域是权威服务器，它最知道清华的，所以可以return，一级一级return，最后返回给北大，北大也知道映射关系
但问题是根服务器负担太重。
==迭代查询==
根及各级域名返回的不是查询结果，而是下一个NS的地址，最后由权威名字服务器给出解析结果。
==DNS协议，报文==
DNS查询和应答的报文格式一样，通过flags区分它是什么。
ID是为了一同发起多个查询，最后通过ID返回给不同的人。
==新增一个域==
在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名 和 域名服务器的地址
其实就是维护指针，让上级域知道新增子域的名字服务器的名字，也知道新增子域名字服务器的名字对应的IP地址。
2.6 P2P应用
与c/s应用不同，它自己本身即是客户端也是服务器，在某些会话上它是客户端，在某些会话上是服务器。
纯P2P架构
- 没有（或极少）一直运行的服务器
- 任意端系统都可以直接通信
- 利用peer的服务能力
- Peer节点间歇上网，每次IP地址都有可能变化
例子：文件分发，流媒体，VoIP
P2P系统有几种运行方式，管理模式
非结构化P2P
==问题==
如何定位所需资源
如何处理对等方的加入与离开
集中化目录
上线时，向集中式目录服务器表明自己上线了，告诉自己的ip以及自己的资源。
但这种集中式有问题：单点故障（集中式服务器宕机），性能瓶颈（很多人同时和集中式服务器连接），侵犯版权（pear文件的上传下载，很难确定谁侵权）
- 完全分布式
- 没有中心服务器
- 开放文件共享协议
当某个节点想查询某个资源，先向自己邻居发起查询，自己的邻居再向别的邻居发起查询。这种方式叫“泛洪”。拥有该资源的节点反向作出应答。目录问题就解决了。再向拥有该资源的节点发出请求。
问题：泛洪停不下来
解决：
- TTL：设置每过多少下不再泛洪，有限的泛洪。
- 让中转节点记住从哪来的，不再回去了。
- 混合体
组长和组长之间是分布式的，组长和组员是集中式的。
组长跟踪其所有的孩子的内容。 组长与其他组长联系。
DHT（结构化）P2P
pear和pear构成的边是有序的。（环，树）
2.7 CDN
视频流化服务和CDN：上下文
视频流量：占据着互联网大部分的带宽
挑战：
- 规模性：单个超级服务器无法提供服务
- 异构性：不同用户拥有不同的能力（有线接入和移动用户：带宽丰富和受限用户）
解决方案：分布式的，应用层面的基础设施
多媒体：视频
CBR（constant bit）：以固定速率编码
VBR（variable bit）：视频编码速率随时间的变化而变化
例子： MPEG1 MPEG2 MPEG4···············································································
存储视频的流化服务
视频点播，如果全部下载好再看，那需要等待很久。流化服务就是一边下载一边观看，就像平时看影片一样。
多媒体流化服务：DASH
Dynamic Adaptive Streaming over HTTP 基于HTTP的动态自适应流
- 服务器
将视频文件分割成多个块
每个块独立存储，编码于不同码率 （多个版本）
==告示文件==（manifest file）：提供不同块的URL
- 客户端
先获取告示文件
周期性的测量服务器到客户端的带宽
查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围
（如果带宽足够，选择最大码率的视频块）
（会话中的不同时刻，可以切换请求==不同==的编码块）取决于当时的可用带宽
2.8 TCP套接字编程
Socket编程
应用进程使用传输层提供的服务才能交换报文，实现应用协议，实现应用
TCP/IP：应用进程使用Socket API访问传输服务
地点：界面上的SAP（Socket） 方式：Socket API
==目标==：学习如何构建能借助sockets进行通信的C/S应用程序
socket：分布式应用进程之间的门，传输层协议提供的端到端的服务接口
2种传输层服务的socket类型：
TCP：可靠的、字节流的服务
UDP：不可靠（UDP数据报）服务
TCP套接字编程
==服务器首先运行，等待连接状态==
1.服务器进程必须先处于运行状态
- 创建欢迎socket
- 和本地端口捆绑
- 在欢迎socket上阻塞式等待接收用户的连接
==客户端主动和服务器建立连接==
2.创建服务端本地套接字（隐式捆绑到本地port）
- 指定服务器进程的IP地址和端口号，与服务器进程连接。
3.当与客户端连接请求到来时
- 服务器接受来自用户端的请求，接触阻塞式等待，返回一个新的socket（与欢迎socket不一样），与客户端通信
- 允许服务器与多个客户端通信
- 使用源IP和源端口来区分不同的客户端
4.连接API调用有效时，客户端P与服务器建立了TCP连接
TCPsocket编程
==C/S模式的应用样例==
客户端在控制台输入小写字母发给服务器，服务器返回小写字母给客户端。
跟上面的步骤一样，服务器先建立welcomesocket，包含了自己的IP和port，阻塞式等待客户端来连接。
客户端建立clientsocket（包含服务器的ip和port），服务器建立新的socket，包含自己的ip和port和客户端的ip和port，客户端给服务器发送请求，把小写字母发送过去，然后服务器处理后发回给客户端。
然后关闭connectionSocket，服务器继续等待连接。
补：socket都是一个整数，包括自己学习java操作对象时，也是操作一个整数句柄，而不是操作文件本身。
2.9 UDP套接字编程
没有握手，UPDsocket只和本地ipport捆绑。
发送端在每一个报文中必须明确指明目标的ip和port，不然不知道发给谁。
服务器必须从收到的分组中提取出发送端的IP和port
与TCPsocket差不多，但服务器只用一个socket去进行一系列操作。
而且服务器只保存自己的ip和port，所以每次请求都要包含发送端的ip和port，否则收到后不知道往哪回复。
第三章：传输层
3.1概述传输层服务
传输服务和协议
- 为运行在不同主机上的应用进程提供逻辑通信（应用进程的通信需要传输层双方TCP的配合进行）
- 传输协议运行在端系统
- 发送方：将应用层的报文分成报文段，然后传递给网络层
- 接收方：将报文段重组成报文，然后传递给应用层
- 有多个传输层协议可供应用选择
- Internet：TCP和UDP
传输层 vs 网络层
- 网络层服务：主机之间的逻辑通信
- 传输层服务器：进程间的逻辑通信
- 依赖于网络层的服务
- 并加强（数据丢失，顺序混乱，加密）
3.2多路复用/解复用
在发送方主机多路复用：
从多个套接字接收来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装（该头部用于以后的解复用）
在接收方主机多路解复用：
根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字（和对应的应用进程）
1 | TCP是带着源ip目标ip源port目标port去传 |
3.3无连接传输UDP
UDP在IP的基础上只增加了复用解复用服务，没有增加更多的东西，因此它和IP提供的服务一样，也是尽力而为的服务。
UDP传输延迟比较小，有可能是后传的先到，有可能会乱序。
无连接
- UDP发送端和接收端之间没有握手
- 每个UDP报文段都被独立地处理
UDP被用于：流媒体（丢失不敏感，速率敏感）
DNS
SNMP
1 | TCP可靠，但是负担大。UDP负担小，效率快。 |
UDP校验和
在发送之前计算校验和，发送后在接收端计算一次，如果不一样就一定发生了差错，抛掉该UDP即可。
如果校验和一致，也不一定是没差错。
3.4可靠数据传输（rdt）的原理
- rdt在应用层、传输层、数据链路层都很重要
- 是网络Top 10问题之一
rdt要向上层提供服务，但rdt依赖的服务却不怎么可靠。因此rdt本层的协议机制要靠哪些安排向上层提供服务？
我们将
- 渐增式地开发可靠数据传输协议（rdt）的发送方和接收方
如果一口气把每个处理机制讲出来很难理解，现在我们假设下层的服务是可靠的，每当下层服务变得不可靠一点点，rdt会做出什么机制应对。
- 只考虑单项数据传递
- 我们使用有限状态机（FSM）来描述发送方和接收方
==Rdt1.0 在可靠信道上的可靠数据传输==
- 下层的信道是完全可靠的
- 发送方和接收方的FSM
- 发送方将数据发送到下层信道
- 接收方从下层信道接收数据
结论：Rdt1.0下层服务完全可靠，rdt只需要做封装解封装
==Rdt2.0 具有比特差错的信道==
比特出错，1变成0,0变成1的反转
发送方有两个状态：一是等待来自上层的调用，二是等待ACK和NAK。 接收方就是等待下层调用。
发送方差错控制编码 接收方差错控制解码
如果没问题，回应ACK，这时发送方就发送新的
如果有问题，回应NAK，这时发送方将存的副本再次发送一次。
**致命问题：packet有可能是错的，那么ACK和NAK 就没可能是错的吗？ **
万一发来的不是ACK和NAK那发送方该传什么。
==Rdt2.1 编号==
所以解决：给packet编号。
发送方发送 p0，接收方传回来的东西出错，那就再重发一次。接收方也就明白了自己传的东西有问题，它就会重传一次ACK，期待发送方的p1。（有序号之后，接收方也就知道发送方发了两次正确的，那扔掉一个就好了）
stop and wait 停止等待协议
一次只发一个分组，等到结果后才会接着发送。
- 两个序列号（0,1）就足够了，因为一次只发送一个未经确认的分组，用0和1区分是否已经接收过即可。
==Rdt 2.2 无NAK的协议==
当发送方发送packet1，本来接收方该回传NAK1，但可以回传ACK0。
发送方期待的是ACK1，可是接收方发送ACK0，意味着packet1出错了。
对前一个分组的正向确认代替对当前分组的反向确认
实际也是对确认分组做编号。
==Rdt3.0 具有比特差错和分组丢失的信道==
分组丢失是因为路由器有队列，队满了就丢失了。
当p1发送出去，发送方等待ACK1，但是p1在接收方这里丢失了，接收方继续等待p1，发送方继续等待ACK1，形成死锁。
超时重传机制
时间设置为比正常往返时间多一点。
当超时，就重传p1。
==新问题：停止等待协议在某种情况链路利用率很低==
如果链路很长，你每次只发送一个packet然后等待回应，那更多的时间都在等待，利用率太低。所以需要流水线协议
铺垫：
滑动窗口协议
发送缓冲区
- 形式：内存中的一个区域，落入缓冲区的分组可以发送
- 功能：用于存放已发送，但是没有得到确认的分组
- 必要性：需要重发时可用
发送缓冲区的大小：一次最多可以发送多少个未经确认的分组
- 停止等待协议=1
- 流水线协议>1,合理的值，不是很大，链路利用率不能够超100%
发送缓冲区的分组
- 未发送的：落入发送缓冲区的分组，可以连续发送出去
- 已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认才能删除
发送窗口：发送缓冲区内容的一个范围
- 那些已发送但是未经确认分组的序号构成的空间
发送窗口的最大值 <=发送缓冲区的值
一开始：没有发送任何一个分组
- 后沿=前沿
- 之间为发送窗口的尺寸=0
每发送一个分组，前沿前移一个单位
接收窗口 = 接收缓冲区
- 接收窗口用于控制哪些分组可以接收
- 只有收到的分组序号落入接收窗口内才允许接收
- 若序号在接收窗口之外，则丢弃
- 接收窗口尺寸Wr=1，则只能顺序接收
- 接收窗口尺寸Wr>1，则可以乱序接收（但提交给上层的分组要按序）
- 例子：Wr=1，在0的位置：只有0号分组可以接收；向前滑动一个，罩在1的位置，如果来了2号分组，则丢弃。
- 接收窗口用于控制哪些分组可以接收
接收窗口的滑动和发送确认
- 滑动：
- 低序号分组到来，接收窗口滑动
- 高序号分组乱序到，缓存但不交付（因为要实现rdt，不能乱序），不滑动
- 发送确认：
- 接收窗口尺寸=1：发送连续收到的最大的分组确认（累计确认）
- 接收窗口尺寸>1：收到分组，发送那个分组的确认（非累计确认）
- 滑动：
GBN协议和SR协议的异同
- 相同
- 发送窗口>1
- 一次能够可发送多个未经确认的分组
- 不同
- GBN：接收窗口尺寸=1
- 接收端：只能顺序接收
- 发送端：从表现来看，一旦一个分组没有成功 比如234都发送出去了，但1没有。要返回1重新发送，从1 2 3 4重新发送。
- SR：接收窗口尺寸>1
- 接收端：可以乱序接收
- 发送端：发送0，1,2,3 一旦1未成功，2,3,4，已发送，无需重发，选择性发送1
- GBN：接收窗口尺寸=1
3.5 面向连接的传输：TCP
==段结构==
TCP
- 点到点：一个发送方，一个接收方
- 可靠的、按顺序的字节流：没有报文边界
- 管道化（流水线）：TCP拥塞控制和流量控制设置窗口大小
- 发送和接收缓存：为了超时重发、检错重发
- 全双工数据：在同一连接中数据流双向流动
- MSS：报文最大大小
MSS就是最上面的报文，它经过传输层要加上TCP的头部，经过网络层要加上IP的头部，最后到了物理层面，以太网最大是1500B，减去TCP和IP的头部就是MSS。
- 面向连接
- 有流量控制：发送方不会淹没接收方
TCP报文段结构
- 其中ACK（确认号）的解释与之前有些不同
接收方如果给发送方传 ACK=555，意味着接收方已经收到了554及554之前的字节，期待发送方从555发
- 接收方如何处理乱序的报文段（看实现者自己的规定 缓存/丢弃）
对主机B来说，收到seq=42，确认号ACK就给主机A传43（代表42及以前我已经收到了）。
TCP往返延时和超时
一个合理的定时器是很有用的。
时间太短的话，确认号还在路上，结果发送方已经等不及了，进行了不必要的反复传输。
时间太长的话，确认号在路上出了问题，等半天也没有进行重新传输
这个值不是一个固定值，适应性的变化。
定期的去测量往返延迟：SampleRTT：测量从报文段发出到收到确认的时间
- EstimatedRTT = （1-a）*EstimatedRTT + a *SampleRTT
估计值 上一次估计值
SampleRTT会偏离EstimatedRTT多远：
DevRTT = （1-β）* DevRTT + β * | SampleRTT - EstimatedRTT |
超时时间间隔设置为
TimeoutInterval = EstimatedRTT + 4*DevRTT
==Rdt==
- TCP在IP不可靠服务的基础上建立了rdt
- 管道化的报文段
- GBN or SR
- 累积确认 接收方如果给发送方传 ACK=555，期待发送方从555发
- 好多段一个定时器，只和最老发出的那个段相关联
- 收到乱序到来的报文段：可以缓存可以抛掉
- 管道化的报文段
- 触发重传：发送方超时/发送方收到某些段的三个冗余确认（快速重传）
第一种
如果超时时间设置有问题，两段ACK都没有传到发送方，但是超时了，发送方重新传92,8字节。
那么接收方回传ACK为什么是120？
接收方回传的ACK应该是传来数据的位置+1。
但是这里会有一个辅助定时器：
如果92到98的到了，不会立马回传ACK=99，会等待辅助定时器超时，超时前会等99到119来，这样的话回传ACK=120即可，少传一次ACK=99，减少对发送方的干扰。但辅助定时器的作用是：如果太久不发ACK，发送方可能会重传。
第二种
99到119到了，92到98没到，乱序到来。这时要快发送ACK=92，让发送方赶快把第一段补给自己。
快速重传
上面已经介绍过快速重传，就是当有一个正常确认后来了三个冗余的确认，那么发送方就会启动快速重传，这种比定时器的超时快一些，能更快的补充缺口。
比如上图情况，当第二段没传到，会发送ACK=50，这是正常确认。
然后第三段到了，会发送ACK=50，第一次冗余确认。
然后第四段到了，会发送ACK=50，第二次冗余确认。
然后第五段到了，会发送ACK=50，第三次冗余确认。
TCP流量控制
接收方会有缓冲区，接收方给发送方的反馈中有接收方缓冲区剩余的字节，发送方就知道最多能发送多少个字节给接收方，这样不至于接收方没地方存导致数据溢出。
连接管理
同意建立连接
两次握手为什么不行？
看右边：
第一次连接请求，然后超时了，又发送了第二次连接请求。但第一次的连接请求现在到了，建立起一个正常的连接，然后开始传数据，又超时了，再次第二次传数据。结果第一次连接接收方收到了数据，只不过ACK回复慢了。然后又收到了第二次连接请求，又同意了，然后又收到了第二次传的数据，又顺理成章收到了，接收方就会以为只是正常的两次连接和两次数据传输，不知道出了问题。
接收方把旧数据当成新数据来收了
三次握手
解决方案：变化的初始序号+双方确认对方的序号（3次握手）
客户端给服务器传自己的序号1，并标明自己要从X接收数据
服务器给客户端传对方的序号1，并表明要从x+1给对方传（表明收到了对方的信息），并表明自己想从y接收数据和自己的序号1（给对方自己的信息）
客户端知道了对方的信息，并表明从y+1传。
对于半连接：当客户端因超时又给服务器发送连接，服务器同意，但是客户端能识别到这是我当时因为超时发送的连接，所以可以拒绝服务器。
对于老数据：因为不会有半连接的问题，所以在客户端因为超时给服务器传数据的时候，服务器就知道没建立连接，所以也就不接收数据。
还有一个诡异的东西，对于上面的老数据被抛弃后，会滞留在网络中。假设客户端与服务器又以相同的端口建立连接，假设这个数据刚好就又到了服务器那里，怎么办？
这时序号就起作用了，我们此时假设是以x和y传递数据，那上次建立的序号过来也没用，不接收。
关闭连接
连接是两端的，要关闭需要进行两次操作，关闭a到b的连接和关闭b到a的连接。
这种半连接的关闭不可靠。因为双方都不知道对方到底关闭连接没。
所以有个方案：
双方取消连接后，建立一个定时器，这个时间内没有数据传输就代表真正关闭了。
3.6 拥塞控制
坏处
- 延迟大
- 为了网络有效的泵出，需要提供很大的速率
- 需要重传一些没有必要的分组，加速拥塞
拥塞控制方法
端到端拥塞控制：
- 没有来自网络的显式反馈
- 端系统根据延迟和丢失事件推断是否有拥塞
- TCP采用的方法
网络辅助的拥塞控制
- 显式提供发送端可以采用的速率
3.7TCP拥塞控制
端到端的拥塞控制机制：
- 路由器不向主机有关拥塞的反馈信息（路由器的负担较轻，符合网络核心简单的TCP/IP架构原则）
- 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作
几个问题：
如何检测拥塞
控制策略
- 拥塞时如何降低速率
- 缓解时如何增加速率
拥塞感知
- 某个段超时了（丢失事件）：拥塞
- 超时时间到，某个段的确认没有来
- 原因1：网络拥塞，路由器缓冲区没空间了，被丢弃了，概率大。
- 原因2：出错被丢弃了，概率小
- 一旦超时，就认为拥塞了，有一定误判，但总体控制方向是对的
- 有关某个段的3次重复ACK：轻微拥塞
- 前面讲的3个冗余ACK就是遇到轻微拥塞了
如何控制发送端发送的速率
维持一个拥塞窗口的值：CongWin
超时时：ConWin降为1MSS，进入SS阶段然后再倍增到CongWin/2（每个RTT),从而进入CA阶段
3个ACK：CongWin降为CongWin/2，CA阶段
如果正常收到ACK：CongWin跃跃欲试
- SS阶段：加倍增加（每个RTT）
- CA阶段：线性增加（每个RTT）
拥塞控制和流量控制的联合动作
- 发送端控制 发送但是未确认 的量同时也不能够超过接收窗口，满足流量控制要求
发送速率 SendWin = min{CongWin,RecvWin}
RecvWin(接收方缓冲区)，CongWin（拥塞窗口）
同时满足拥塞控制和流量控制的要求
TCP公平性
公平性目标 如果k个TCP会话分享一个链路带宽为R的瓶颈，每一个会话的有效带宽为R/K
公平性和UDP
UDP协议下应用发送的数据速率希望不受拥塞控制的节制，所以UDP是有侵略性的
公平性和并行TCP连接
- 两个主机间可以打开多个并行的TCP连接
- Web浏览器
- 例如：带宽为R的链路支持了9个连接
- 如果新的应用要求建1个TCP连接，获得带宽R/10
- 如果新的应用要求建11个TCP连接，获得带宽R/2
第四章：网络层数据平面
4.1导论
==网络层服务==
- 在发送主机和接收主机对之间传送段(segment)
- 在发送端将段封装到数据报中
- 在接收端，将段上交给传输层实体
- 网络层协议存在于每一个主机和路由器
- 路由器检查每一个经过它的IP数据报的头部
==网络层关键功能==
转发：将分组从路由器的输入接口转发到合适的输出接口
路由：使用路由算法来决定分组从发送主机到目标接收主机的路径
- 路由选择算法
- 路由选择协议
转发：通过单个路口的过程
路由：从源到目的的路由路径规划过程
==数据平面、控制平面==
数据平面
本地，每个路由器功能决定从路由器输入端口到达的分组如何转发到输出端口
转发功能：
- 传统方式：基于目标地址+转发表
- SDN方式：基于多个字段+流表
控制平面
- 网络范围内的逻辑
- 决定数据报如何在路由器之间路由，决定数据报从源到目标主机之间的端到端路径
传统方式：路由和转发的相互作用
控制平面：路由算法决定端到端路径
数据平面：IP协议根据转发表决定了IP数据在此路由器上的局部转发
SDN方式：逻辑集中的控制平面
一个不同的（通常是远程的）控制器与本地控制代理（CAs）交互
==网络服务模型==
Q：从发送方主机到接收方主机传输数据报的“通道”，网络提供什么样的服务模型？
对于单个数据报的服务
- 可靠传送
- 延迟保证，如：少于40ms的延迟
对于数据报流的服务
- 保序数据报传送
- 保证流的最小带宽
- 分组之间的延迟差
4.2路由器组成
==路由器结构概况==
高层面（非常简化的）通用路由器体系架构
- 路由：运行路由选择算法/协议-生成路由表
- 转发：从输入到输出链路交换数据报-根据路由表进行分组的转发
==输入端口功能==
输入端口网络层需要一个队列，因为是多对一的，很多输入对应一个输出
==第一代路由器==
通过内存交换
- 在CPU直接控制下的交换，采用传统的计算机
- 分组被拷贝到系统内存，CPU从分组的头部提取出目标地址，查找转发表，找到对应的输出端口，拷贝到输出端口
- 转发速率被内存的带宽限制(数据报通过BUS两遍)
- 一次只能转发一个分组
==第二代路由器==
通过总线交换
- 数据报通过共享总线，从输入端口转发到输出端口
- 总线竞争：交换速度受限于总线带宽
- 1次处理一个分组
- 对于接入或企业级路由器，速度足够（但不适合区域或骨干网络）
==第三代路由器==
通过互联网络（crossbar）交换
- 同时并发转发多个分组，克服总线带宽限制
- 当分组从端口A到达，转发给端口Y：控制器短接相应的两个总线（短接两个，剩余的一个就能转发）
- 高级设计：将数据报分片为固定长度的信元，通过交换网络交换
==输出端口==
同样，需要缓存。需要排队，可能会抛弃。
由调度规则选择排队的数据报进行传输
==调度机制==
调度：选择下一个要通过链路传输的分组
一.FIFO：按照分组到来的次序发送
tail drop：丢弃刚到达的分组
priority：根据优先权丢失/移除分组
random：随机地丢弃/移除
优先权
发送最高优先权的分组
多类，不同类别有不同的优先权
- 类别可能依赖于标记或者其他的头部字段
- 先传高优先级的队列中的分组，除非没有（有高不传低）
二.循环调度
红黄蓝红黄蓝
4.3 IP Internet Protocol
==IP分片和重组==
IP传递的时候会遇到一个问题，传递的IP长度为4000，但接收
评论区
欢迎你留下宝贵的意见，昵称输入QQ号会显示QQ头像哦~