计算机网络
2022/0221
一 网络协议& TCP/IP网络协议

二 数据链路层
主要信道:
1 点对点通信信道(一对一)
2 广播信道(一对多)
数据部分长度上限: 最大传输单元MTU(Max Transfor Uint)

三 网络层
数据报传输格式 IP数据报

1 版本 指定通信双方IP协议版本要一致(ip协议 ipv4或是 ipv6)
2 首部长度: 首部= 固定20字节 + 可变部分 首部长度记录了首部总长度(可变部分不是变化的么)
3 区分服务: 区分服务时候才会用,平时不用
4 总长度: 总长度= 首部长度 + 数据部分长度 16位即为16个1, 10进制数就是2^16-1 = 63535个字节 64kb5 标识: 下层传送切片相关, 数据报,数据部分太长时候, 给下层的数据链路层传送时候需要分片,用这个记录标识(ip数据报不用建立连接,所以也不需要,标识需要传送)
6 标志:下层传送切片相关, 1为还有切片,0 为没切片了
7 片偏移:下层传送切片相关, 标记重组位置
8 生存时间: 超时了,就丢弃这个ip数据报
9 协议: 定义运输层使用什么协议 TCP/UDP啥的
10 首部检验合: 检验数据报首部(注意: 不检验数据部分,因为每经过一个路由器,时间,标志,位移都可能发生变化)
11 可选字段:扩容字段,排错,测量,安全啥的
Ps: 10为啥不检查数据部分,效率被
四 运输层/传输层
UDP 用户数据报协议

Udp的数据报的数据长度是 64kb 16位就是16个1
一: udp对比ip数据报增加功能
1 分用复用功能
2 检验和功能(ip数据报只是检验首部, 不检验数据, udp全检验)
二: UDP特点
1 udp无连接 (为了减少开销, 不需要建立连接和释放)
2 udp尽最大可能交付(不保证可靠交付, 因为没有维持复杂的连接状态)
3 udp面向报文
3.1 应用程序交下来的报文段, 添加首部就交给IP层, 封装成ip数据报, 就是tm在添加个首
3.2 运输层接收到网络层的Udp数据报, 也就是去掉udp首部上交给应用层
4 udp没有拥塞控制 (网络的拥塞,不会降低主机的发送速率降低, 对于某些应用, 需要恒定的数据发送速率, 而且网络拥塞时候, 不能有太大的延迟,用udp正合适, 例如ip电话或是实时视频会议)
5 udp支持一对一 , 一对多, 多对一, 多对多.
6 udp首部开销小(8个字节, tcp20个字节, 使用不适用拥塞控制功能的udp, 会是多个主机都以恒定的速率发送数据, 导致网络拥塞)
数据报 = 数据报头部+ 数据报 组成 支持最大传输数据是64kb. 怎么来的呢
数据报头部定义的 你的长度留出来几个字节存储, 例如8位 则最大长度是8个1, 换算10进制长度就是多少个字节
1 源端口号: 源端口号(当前主机ip地址+ 端口号) 需要对方回信选用, 不需要时候可用全0
2 目的端口: 目标ip地址 + 端口号
3 长度: 数据报长度
4 检验合: 检验传输过程是否有错,否则丢弃
5 伪首部: 检验合时候用, 不向上或是向下传递
三: TCP 运输层数据段传输格式

四: tcp 首部
(15)选项: ?? 规定了tcp数据报的长度(数据报总长度包括首部20字节+ 数据报长度), 原则上是越大越好,但是呢,要避免数据链路层ip数据报承载,被切片传送的限定为佳
首部: 固定 20个字节 160位 + 选项 + 填充(非固定)
1 源端口: 需要对方回信本主机ip地址 + 端口号, 否则全0, 分用复用通过端口实现 (分用: 从下自上,传给各个应用层的进程,反之从上向下,多个进程传出去)
2 目的端口: 目标ip地址 + 端口号
3 序号: 存的是本段报文段所传送的字节流的第一个字段的序号, 范围(1 ~ 2^32-1), 报文段序号, 字节流是按序编号的,
4 确认号: 存的也是序号, 期望接收到的序号 (例如: B上次传过来A的序号是301,数据长100字节,下次序号该400了, 则B期望A下次传过来的是400)
5 偏移量: 标记数据段首部距离 tcp数据起始多远,标记的是数据报首部长度 (除了20自己固定的首部长度, 还有选项部分嘛)
6 保留: 保留为日后使用,目前置为0 ?? 不知道毛意思
7 URG: 紧急, 标志,数据段中有紧急数据,优先处理,交付到应用层 (正常要等到数据缓存在tcp缓存尾部,才会依次处理),URG为1时候,将紧急数据插入到本报文段的最前面
8 ACK: 确认 为1 报文段有效 tcp规定建立连接后, ACK为1时候才有效
9 PSH: 推送 为1 报文段尽快被处理,不用等到TCP缓存存满之后才处理 (ps感觉优先级比紧急低呢)
10 RST: 复位 为1 代表TCP建立了错误连接, 需要释放连接, 然后重新建立连接
11 SYN: 发起建立连接请求报文段 为: SYN为1, ACK为0, 若同意连接,则响应报文段使用 SYN为1 , ACK为1 建立新的连接
12 FIN: 为1 标识需要释放一个连接 (例如报文段数据发送完毕)
13 窗口: 指的是发送报文段一方的接收窗口 (注意此时他是发送方,但是描述的是他接受的能力), 描述了一个发送发的接收数据的能力
14 检验和: 检测数据正确性包含 数据段首部 + 数据段数据 ,计算检验和字段时候开启伪首部
15 紧急指针: URG为1时候才有意义,标记了URG的位置
16 选项: 如果没使用选项时候, TCP首部长度为20个字节 160位
Ps: 序号补充: 例如序号存的是301, 数据是100字节, 表示,本段报文段第一个字节需要是301 ,最后一个字节序号是400,下一个报文段的序号就要401开始了.
五: 复用和分用
复用: 应用层的各个进程是通过运输层在传导IP层的这叫复用
分用: 运输层从IP层收到发送给各个应用进程的数据,必须分别交付给指明的各个应用进程, 叫分用
六: 进程
进程: 应用层的进程使用一个不大不小的数字表示的, 具体表示用端口号
Tcp/ udp 协议中有源端口号, 和目标端口号, 表示源主机的某个进程, 到目标主机的某个进程 (相关协议端口协议)
所以通信的双方, 需要知道源主机的ip地址(哪台主机), 端口号(表示哪个进程), 目标主机IP得知和端口号也一样
七: 端口分类
一 服务端端口号

1 熟知端口号 (标记服务端进程)
数值 0~1023之间
INNA(www.inna.org)指派tcp/ip 一些重要应用程序的端口号(熟知端口号的应用程序) 例如 http:端口号80 https: 443 dns: 53
2 登记端口号 (标记服务端进程)
不是熟知端口号应用程序使用的, 需要在INNA按照规定手续登记,防止重复, 数值 1024~ 49151
二 客户端端口号
数值45152 ~ 65535
客户端运行时动态选择, 也成端在端口号, 客户端服务端通信结束,这些端口号就不存在了,可以给其他进程使用
ps: 暂时理解为 端口代表一个应用程序吧 !!!!! 存疑~~
一 tcp特点
1 面向连接的运输层协议, 使用tcp协议前,需要建立连接,传输结束需要释放连接
2 每条tcp连接只能是, 端点到端点连接 (端点为套接字socket = IP地址 + 端口号)
3 tcp协议可靠交付, 无差错, 不重复, 不丢失, 按序到达
4 tcp采用双工全通信, 就是tcp通信的连段通信过程中既可以处理发送和接收, 同时有发送缓存和接收缓存
发送时候: 应用程序把数据通过端点(socket)传送给tcp的发送缓存, 合适时间,处理发送,
接收时候: 数据通过接收端端点(socket)存放在tcp接收缓存, 应用程序合适的时候, 读取接收缓存
5 面向字节流, 流是指流入或是流出进程的字节序列, 应用程序和tcp交互是一个个数据块(大小不等), tcp把应用程序交付的数据块看做是一个个无结构的字节流
二: tcp连接
每条tcp有两个端点, 端点叫套接字(socket)或是插口
套接字: 端口号拼接到IP地址构成套接字 例如IP地址为192.168.1.1 端口号为80(http应用)则套接字为192.168.1.1:80, 套接字 = (ip地址: 端口号)
tcp连接 :: = {socket1, socket2} = {IP:port1, IP: port2}
三: 可靠传输的工作原理
首先tcp所在的运输层下面的网络层, IP数据报是不可靠的传输, 尽最大努力传输, 怎么保证tcp可靠传输呢
1 传输通道不产生差错
2 发送方不管多快发送, 接收方都来得及处理
(实际条件不会满足上述两点)
1 传输发生差错, 让发送方重传差错数据或超时重传
2 当接收方来不及接收数据处理时候, 通知发送方降低速率(通过调整接收方窗口调节)

例如 客户端A——服务端B 之间数据传输 (5-9 a)
1 正常数据发送流程 A发送数据, B确认数据, A再发,B在确认…..
2 解决发送失败重传流程(发送报文失败, 客户端问题 5-9 b)
Tcp协议 解决差错数据, 每次发送数据都会有个超时计时器
例如 当数据发送失败, 或是B检测出错误数据报, 啥也不做,等着超时重传就行了
2.1 A发送报文(保存发送数据分组的副本,超时重传时候用),数据分组被服务端确认后, 清空副本
2.2 区分哪个数据分组收到与否, 需要给数据分组编号(序号)
2.3 超时重传计时器会比正常发送数据时间长一点

3 确认丢失或是迟到(说的是服务端 数据接收)
(5-10 a)的情况, B确认请求在A超时重传计时器之间延迟, 则A进入超时重传, 重新发送数据M1, B重新发起确认请求并且丢弃重复的M1数据
(5-10 b) 的情况 B确认请求在A超时重传计时器之外延迟, 则A进入超时重传, 重新发送数据M1, B重新发起确认,A发起了新的数据M2,此时M1数据确认才到来, 则A啥也做
四 发送数据原理(连续ARQ协议)
发送方维持发送窗口, 等待接收方确认

注意: 接收方采用累积确认方法, 不会对每个分组逐一确认(2就是一个分组),如图接收到五个分组后再确认, 当然如果出错了,例如5个分组中少了2个分组,则五个分组重新传
五 Tcp可靠传输实现

接着滑动窗口讲, 首先发送方窗口长度是由接收方决定的, tcp首部有窗口字段,所以发送方的窗数值不能大于接收方的窗口值
问题1: 若报文段无差错, 但是序号有问题, 或是缺了中间序号
方案: 通常是先存在接收缓存窗口里面, 等缺失的字节收到后, 在上传到应用层
问题2: 怎么处理缺失中间序号的报文段
方案: 接收到数据序号不连续时候, 告诉发送方哪个需要重新传, 接收过的, 可以不必再重新传了
固定tcp首部字段中没有能标识序号错乱处理边界的字段, 所以会在首部选项字段(长度可变)中新增允许SACK字段, 允许存储无序序号处理
六 超时重传
采用自适应算法
发送数据时间到接收数据确认时间, 时间差称之为 往返时间RTT, 这个重传时间是动态计算出来的
七: TCP运输连接管理(三次握手 这Tm是重点)

建立连接流程
1 A 发送请求连接报文段 (不能携带数据)
2 B 对A的请求报文段确认 (不能携带数据)
3 A收到B的确认请求, 给一个再确认 (可以携带数据)
问题1 按说两次握手就能建立连接了,为啥客户端还要再次确认呢?
例如 (处理极端的错误)
客户端A 和服务端B建立连接
A发送了两次建立连接请求, a1, a2 ( a1由于网络原因, 延迟了)
a2正常连接,传数据后,释放结束了
本来失效的报文段a1 刚发送到B客户端,B以为是A重新建立的连接呢,像A发起确认请求,再次建立连接,如果不采用第三次握手,B发起确认,连接就建立了
A没有发起建立连接,所以不会去处理B的确认请求,也不给B发送数据,B却以为连接已经建立的, 一直在等待A发送数据呢,资源浪费.
哄咔嚓哄咔嚓
八: TCP释放连接 (四次挥手)

MSL:最长报文寿命
1个MSL建议设置为2min
问题: 为什么要等待2MLS时间呢??
如果你能保证客户端A最后一次发送的确认请求一定发送成功, 那就可以,现实肯定是不可能的
否则, 需要延长一点时间, 服务端B没有收到客户端A的确认请求,会重新发起断开请求,这样才能保证客户端A接收到
ps: 客户端A发送确认就断开的前提是, 保证这次发送确认一定能成功, 否则就需要留着TCP连接通道, 给服务端发送重新断开请求留下通道, 让客户端能再次确认
保活计时器
服务端设计的
例如Tcp连接后, 客户端故障没办法发送数据给服务端, 客户端每发送数据给服务端, 则服务端重置一次保活计时器默认2小时, 2小时没收到数据, 则75秒发送一次探测报文段给客户端, 发送10次,如果还是没有响应, 则认定客户端故障, 关闭tcp连接
习题:
运输层提供了进程之间的逻辑通信, 向应用层屏蔽了下面网络层的细节(路由选择协议等)看着像是两个进程之间好像在运输层有条实体传输通道一样
网络层是主机之间的通信 (ip地址主机到 ip地址主机), 运输层之间通信是为应用层提供端到端的逻辑通信(socket到socket)
Ip电话, 视频会议
Udp有检验和字段, 创建伪首部, 检测udp头部和数据部分, 发现有问题数据直接抛弃
需要解决
1 确认机制 ,发送方发送,接收方收到给个确认
2 重传机制 ,超时没有确认的的需要重传
3滑动窗口, 保证窗口接收,我发送的快了慢了能调节接收窗口大小
1.2 属于传输正确性范畴, 3属于传输调节问题
传输层无法解决只能搬到应用层处理
开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。
检验数据报正确性, 包含报文段首部, 和数据
1 UDP是面向报文的 发送方应对, 应用层传下来的报文, 不拆分, 不合并, 加上首部交给网络层, 也就是说不管大小, 从应用层传给传输层
接收方接应用层接收来自udp的报文, 去掉首部, 发送给应用程, 所以控制报文大小, 是靠应用层处理的
2 Tcp和应用层交互是一个个数据块, tcp把这些数据块把这些数据块看成是一个个字节流, 通过发送窗口发送, 接收窗口接收
端口号: 表示一个应用进程, 使不通操作系统的计算机之间可以通信
标记服务端进程的熟知端口号, 和非熟知端口号, 客户端端口号(临时的)
计算检验和 检验头部和数据部分正确性的, 不参与向下传输或是向上传输
1 udp新增了分用,复用功能
2 增加了检验数据部分和首部(ip数据报仅仅检验首部正确性)
① 基于连接与无连接(是指传输数据之前)
② 对系统资源的要求(TCP较多,UDP较少)
③ UDP程序结构较简单,首部开销只有8个字节,而TCP有20个字节。
④ 流模式与数据报模式,UDP没有拥塞控制,UDP中当网络发生拥塞不会使源主机的速率降低,
多用于实时应用中,如IP电话,实时视频会议等。
⑤ TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。
⑥每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。
⑦ TCP的逻辑通信信道是全双工的可靠信道(及时发送方也是接收方),UDP则是不可靠信道。
⑧ TCP多用于传输大量数据,UDP多用于传输少量数据
五 应用层
一 DNS

DNS: 域名系统是互联网的一个服务
域名和ip地址映射的数据库
例如: www.baidu.com 对应 ip地址192.168.1.1 根据域名去dns服务器解析出对应的ip地址, 从而使主机可以和另一台(已知域名的主机)可以数据连接
清华大学邮箱域名: 如图 mail.tsinghua.edu.cn (这样在全球internet中有了一个唯一地址)
域名和主机的IP是一一对应的关系
PS: 这个DNS服务,就是通过DNS服务(包含许多域名解析服务器)解析出对应主机的ip地址的服务
二 FTP
FTP: 文件传输协议
解决实际问题: 例如一台主机从另一台主机上获取文本文件(txt文件)

工作流程: 文件传输时候, ftp客户端创建两个并行tcp连接, 控制连接和数据连接, 通话期间两个连接都都保持打开状态
1 控制连接: 控制连线, 和给服务端发送控制进程
2 数据连接: 负责传输数据
三 TFTP: 简单文件传输协议
采用UDP传输
** 四 万维网**

万维网是一个大型的连接式的信息储存所
万维网具体是用链接的方式, 可以从互联网上由一个站点访问另一个站点, 主动的获取信息
从一个连接, 访问到一台主机存储的信息, 审阅呀, 下载文件等
一 URL (统一资源定位符)
1 概念: 表示 得到互联网资源的位置及访问资源的方法
资源: 包括目录文件, 图像, 音频, 视频
二 URL组成
协议:// <主机>:<端口>/<路径>
协议:// 什么协议 例如 http(超文本传输协议) ftp(文件传送协议)
端口http为80 路径 有时候可以忽略不写
例如 baidu.com 输入浏览器后, 会被自动补齐 http://baidu.com
下图是http协议的url

路径后缀的index.html为html编写出来的文件
PS: URL里面不区分大小写
Ps: 这个主机域名写ip地址也ok吧 ~~~~~!!!!
三 HTTP
概念
http 定义了浏览器怎么向万维网服务器请求万维网文档, 万维网服务器怎么把文档传给浏览器
主要是交换资源(文件, 声音, 视频, 图像)

第三次客户端发送收到确认请求时候, 把http请求带给服务器, 服务器接收到请求报文, 回复响应报文
http/1.0(非持续连接)(如上图) 每次访问服务器都需要, 时间是2rtt时间的开销
Http1.1 (持续连接 http1.0升级版) 就是服务端发送了响应报文后, 都会保持连接一会, 所以客户端只要再次访问这个服务器时候, 都不需要在浪费两次rtt开销了,可以直接发送请求/响应报文交互数据了
http1.1分两种 非流水方式 流水方式
非流水方式: 客户端发送请求报文后, 得到服务端的响应报文后, 才能发新的请求报文
流水方式: 客户端发送请求报文后, 在的到服务端的响应报文前, 可以发送新的请求报文(效率更高)
四 代理服务器
概念
就是缓存了之前一些请求和响应在本地磁盘, 代理服务器发现新的请求存在缓存中, 就返回暂时的响应, 不需要用url去互联网访问该资源

ps:代理服务器, 就是泥马缓存请求和响应, 代理服务器没有当前请求,则作为客户端发请求向源点服务器请求资源, 有的话作为服务端给校园网浏览器发送响应请求
五 HTTP报文结构(重点)
下图 请求报文& 响应报文
1 组成分为三部分
(1 )开始行 区分请求行还是状态行(请求行/ 状态行) CR(回车) LF(换行)
(2) 首部行 说明浏览器, 服务器或是报文主体信息
(3) 实体主体: 请求也好,响应也好一般不写这个报文
ps: 请求行 请求头 请求体/ 响应行 响应头 响应体

2 请求报文
请求行
方法(get post) url: 统一资源定位符号(协议://主机/端口号/路径) 版本: http版本

请求报文(全….下图)

上图: 首部字段名: 值(回车换行)HOST(首部字段名) : ww.xyz.edu.cn(值) ,这个请求没有实体主体
ps: 包含请求行, 首部行, 没有主体实体(上图)
3 响应报文

响应行
版本 状态码 短语 例如 HTTP/1.1 202 Accept {接受}

响应报文 (全….下图)

ps: 包含响应行, 首部行, 没有主体实体
六 服务器存储用户信息 (Cookie)
概念: 浏览器用cookie标识某台主机, 目的记录浏览器的用户的行为
浏览器访问服务器, 则服务器给浏览器生成一个cookie, 发送响应报文时候追加一行首部行 Set- cookie: 123456
浏览器接收到服务端响应报文中cookie,缓存, 下次发送服务端请求报文时候,同样首部行添加 Cookie: 123456给服务器
七 万维网文档
就是这个网页咋写出来的 h5 cs js 写的
超链接: 需要先添加个Url, 要不你点击咋跳转的, 没那么神奇
八 收发邮件
发送邮件SMTP协议
接收邮件POP3 IMAP协议
get请求数据部分拼接在url后面(那就是在请求行中体现), 一般不包含请求体, 地址中可以看见参数, 由于浏览器限制url长度, 所以传递数据大小被限制
post请求数据被封装在请求体中, 所以数据大小不被限制
区别
1 数据提交方式不同
Get数据?后面拼接在url后面&连接, get数据封装在数据体中
2 数据传输大小不同
http没有规定url的长度, 但是浏览器规定了, IE 2048+35 = 2083字节, 所以get数据传输长度受限制
Post理论上数据传输没有限制, 但是实际上各个web服务器, 对数据提交大小做了限制
3 安全性
Post安全性更高点, 因为浏览器缓存, 看历史记录就能拿到账号密码了
相关连接
https://www.cnblogs.com/lauhp/p/8979393.html
socket组成:
IP地址 + 端口号 (tcp通信的两个端点)
socket的作用:
应用层通过传输层数据通信时候, 计算机操作系统为应用程序与tcp/ip协议交换提供了成为套接字(socket)的接口, 区分不通程序之间的网络通信
socket连接步骤
1 socket服务端监听 -> socket客户端发送请求 -> socket连接确认
socket与http
很多时候需要客户端服务端保持数据实时同步 (需要服务端主动向客户端发送数据)
如果http需要客户端先发送请求报文, 才能获得客户端的响应报文
但是建立socket连接后(tcp), 则客户端可以直接给客户端发送消息
socket长连接
首先tcp是有状态的长连接, 通常说的socket长连接就是tcp连接
http属于短连接, 每次数据传输, 先建立tcp连接, 客户端发送请求, 服务端响应, 然后断开tcp连接.
每一条Tcp连接有两个端点, 就是socket(接口)
socket不是协议, 算是个对TCP/IP协议的封装
Socket有两种连接方式
1 面向udp的无连接的socket 2 面向tcp的有连接的socket
ps: TCP/IP协议指的是四层网络协议
①基于连接与无连接(是指传输数据之前)
②对系统资源的要求(TCP较多,UDP较少)
③UDP程序结构较简单,首部开销只有8个字节,而TCP有20个字节。
④流模式与数据报模式,UDP没有拥塞控制,UDP中当网络发生拥塞不会使源主机的速率降低,
多用于实时应用中,如IP电话,实时视频会议等。
⑤TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证。
⑥每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。
⑦TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道。
⑧TCP多用于传输大量数据,UDP多用于传输少量数据
1 udp报文首部有包长度限制 64kb
2 tcp报文首部没有包长度限制, 依靠ip层处理
相关连接
https://www.jianshu.com/p/947a2673102a
网友评论