OSI 七层模型
OSI七层网络模型
TCP/IP四层概念模型
图解计算机网络
TCP/UDP
TCP（Transmission Control Protocol，传输控制协议）是面向连接的协议，也就是说，在收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来
TCP三次握手过程
1，主机A通过向主机B 发送一个含有同步序列号的标志位（SYN）的数据段给主机B ,向主机B 请求建立连接,通过这个数据段, 主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.
2， 主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事: 我已经收到你的请求了,你可以传输数据了;你要用哪佧序列号作为起始数据段来回应我
3， 主机A收到这个数据段后,再发送一个确认应答（ACK）,确认已收到主机B 的数据段:"我已收到回复,我现在要开始传输实际数据了。这样3次握手就完成了,主机A和主机B 就可以传输数据了.
UDP（User Data Protocol，用户数据报协议）
（1） UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
（2） 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。
（3） UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。
（4） 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。
（5）UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。
（6）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。
我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。
TCP与UDP的区别：
1.基于连接与无连接；
2.对系统资源的要求（TCP较多，UDP少）；
3.UDP程序结构较简单；
4.流模式与数据报模式 ；
5.TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。
TCP如何实现可靠传输
网络通信中要解决几个核心问题
- 数据错误
- 数据丢失
- 数据失序
- 流量匹配
- 拥塞控制
不可靠信道的特点决定了可靠服务传输的复杂性
构造可靠传输协议
现实：信道干扰往往带来bit差错
问题：怎么处理bit差错？
差错检验
差错恢复
rdt2.0：处理bit差错
如何检测bit差错：checksum()
如何恢复bit差错？
肯定确认：接收方告诉发送方数据分组正确到达
否定确认：接收方告诉发送方数据分组出错
重传：发送方收到否定确认后重传该分组
rdt2.0的机制：停止等待协议(Automatic Repeat reQuest, ARQ)
检测：接收方检测bit差错
反馈：接收方发送确认消息(ACK或NAK)给发送方
问题：当接收方的ACK/NAK信息出错了怎么办？
发送方不知道接收方发生了什么情况
重传？
可能会导致接收方数据重复
问题的关键是什么？
识别重复的数据分组！
接收方怎么识别？
问题：接收方如何识别重复分组？
方案：
为数据分组进行编号
接收方丢弃重复分组
重传肯定确认(ACK)
发送端:
为分组编号
两个编号 {0,1}足矣
必须检测确认信息是否出错
状态数量翻倍(相对于rdt2.0)
在状态值中必须记录当前的数据分组号是0 还是 1 .
接收端:
必须检测数据分组是否出错
必须检测数据分组是否重复
状态值暗示了期待的分组号
注意: 接收方不知道最后的确认信息是否被发送方正确收到
新问题
如何处理分组或确认的丢失？packet or ACK lost
rdt3.0：处理信道中的bit差错和分组丢失
差错控制：检测、确认、重传
分组丢失？
重传！！
问题关键：如何让发送方认识到分组丢失了？
解决思路：
如果数据包“失联”了…
发送端设置“定时器”timer
超时重发！
接收方仍然会收到重复分组
没关系！——分组编了号的！
rdt3.0 貌似可以正常工作了！！
事实如此！可靠性有保障了！
但是，效率如何？
rdt3.0：停止等待——大部分的时光都消耗在等待中!
问题：
如何提高吞吐量？
提高网络利用率？
从停止等待协议到流水线协议
流水线：
发送方发送一个数据分组之后，在对方确认之前，可以继续发其他分组
问题：让流水线工作的前提？
数据分组的序号空间增大
在发送方和/或接收方需要设置缓存
优点：成倍地提高网络的通信效率
问题：流水线中如何实现差错控制？
出现分组丢失、损坏或延时后如何考虑重传？
回退N步(Go-Back-N)
选择重传
回退N步
发送方：
允许发送方发送多个分组，而不需等待确认
未确认的分组数
发送方的缓存容量是有限度的！
不能让发送方“肆无忌惮”地发数据
否则跟UDP没太大区别了
是流控制的需要：发送速率不能大于接收速率！
也是拥塞控制的需要：不要擅自给网络添堵！
接收方也要设置定时器：用于处理丢失重传问题
问题：设置多少个？
多多益善？
定时器也耗费资源!
接收方：
前提：
接收方没有缓存(降低成本)
只接收有序的分组(向上提交)
会丢弃失序的分组(有点可惜)
问题：接收方肿么确认分组？
场景1：分组丢失—数据失序
接收方：丢弃失序分组
场景2：确认丢失—累积确认
ack3 ：小于等于序号3的分组�都被确认收到了
场景3：分组出错—重复确认
接收方：重复确认
发送方：可在超时之前就重传
果断处之
又回到发送方：
接收方没缓存-机制简单，重担落在发送方了！
引入一个新概念：滑动窗口(slide window)
窗口长度是固定的：N
存在的问题：
接收方丢弃所有失序分组——可惜啊！
发送端可能一下子要重传多个分组
选择重传
发送方：允许发送方发送多个分组，而不需等待确认
接收方：对正确接收的分组进行逐个确认
分组失序：把分组缓存，向上层有序提交分组
发送方有选择地重传
哪个分组的ack没收到，就重传那个分组
发送方和接收方都有缓存(滑动窗口)
接收方：
前提：
接收方有缓存
可接收失序的分组(暂缓提交)
问题：接收方肿么确认分组？
场景1：分组丢失—数据失序
接收方：缓存失序分组
逐个确认正确收到的分组
场景2：确认丢失—超时事件
发送方重传
场景3：分组出错—重复确认
接收方：重复确认
发送方：可在超时之前就重传
果断处之
实现可靠传输的基础构件
检验和
定时器
序号
- 序号空间
确认 - 确认序号
- 累积确认
- 重复确认
- 逐一确认
窗口、流水线 - 窗口尺寸
- 窗口变量：base， nextsqnum
HTTP请求
http协议类型有8种，分别是：
OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*’的请求来测试服务器的功能性。
HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
GET：向特定的资源发出请求。
POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。
PUT：向指定资源位置上传其最新内容。
DELETE：请求服务器删除Request-URI所标识的资源。
TRACE：回显服务器收到的请求，主要用于测试或诊断。
CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
构建基于REST API的开发者对于何时使用HTTP PUT与POST有很大的误解与困惑。有些人认为POST 应用于创建资源，而PUT则用于更新资源。其他人则认为PUT用于创建而POST用于更改资源。这两种说法都不太确切。
通常，开发者将每个HTTP方法与CRUP操作一一对应。
CRUD HTTP
Create POST
Read GET
Update PUT
Delete DELETE
① 1** 用于指定客户端（临时）响应相应的某些动作
100 继续 101 交换协议
② 2** 用于表示请求成功
200 OK 201 已创建 202 接收 203 非认证信息 204 无内容 205 重置内容 206 部分内容
③ 3** 用于重定向
300 多路选择 301 永久转移 302 暂时转移 303 参见其它 304 未修改（Not Modified） 305 使用代理
④ 4** 客户端错误
400 错误请求（Bad Request） 401 未认证 402 需要付费 403 禁止（Forbidden） 404 未找到（Not Found） 405 方法不允许
406 不接受 407 需要代理认证 408 请求超时 409 冲突 410 失败 411 需要长度 412 条件失败 413 请求实体太大
⑤ 5** 服务端错误
500 服务器内部错误 501 未实现（Not Implemented） 502 网关失败 504 网关超时 505 HTTP版本不支持