文章目录

互联网体系结构

OSI参考模型
TCP/IP四层模型
五层模型架构

传输层

传输层服务和协议

UDP协议
TCP协议

HTTP
Cookie技术

互联网体系结构

OSI参考模型

1 物理层：解决单一bit传输问题

特性：机械特性（接口的几何形状，插口）、电气特性（电平、电压大小）、功能特性（多少个引脚具体的功能）、规程特性（接口工作过程遵循的过程）

比特编码

数据率

比特同步：发一个收一个，不会错过乱序，时钟同步

传输模式：单工（电视）、半双工（对讲机）、全双工

2.数据链路层：相邻结点到节点的数据传输

组帧

物理寻址：帧头增加发送端和/或接收端的物理地址表示数据帧的发送端和/或接收端

总线结构时，一个结点与多个结点相连，需要物理地址判断到底发给哪个结点

流量控制：匹配接收端和发送方的数据率，避免淹没接收端

差错控制：检测并重传损坏或丢失帧，避免重复帧

访问控制：在任一给定时刻那个设备具有链路的控制使用权

3）网络层：负责源主机到目的主机数据分组的交付

可能穿越多个网络

逻辑寻址：全局唯一逻辑地址，确保数据分组被送达目的主机

路由：路由互联和路由寻址

分组转发

4）传输层：接收上层，构成“段”

负责源-目的（端到端）（进程间）完整报文传输

分段与重组

SAP寻址：确保将完整报文被正确进程接收，如端口号

连接控制，逻辑上的链接，不是电路的物理连接

流量控制

差错控制

5）会话层：表示层接收其pdu，构造会话层pdu，并不会对表示层pdu分割，最多插入控制信息

对话控制:建立、维护

同步：数据流中插入“同步点”

最薄一层，实际中可能并没有这一层

6）表示层：

解决源主机与目的主机交换信息的语法语义问题

数据表示转化：转化为主机独立编码

加密/解密

压缩/解压缩

实际网络里也不独立存在，由应用层完成功能

7）应用层：最丰富一层

支持用户通过用户代理或网络接口使用网络（服务）

典型应用服务：FTP HTTP SMTP

TCP/IP四层模型

五层模型架构

在这里插入图片描述

传输层

传输层服务和协议

传输层服务：为运行在不同Host上的进程提供了一种逻辑通信机制
TCP UDP
传输层位于网络层上，依赖于网络层服务，对网络出服务进行（可能的）增强
Internet的传输层协议：
TCP（可靠。按序的交付服务）拥塞控制，流量控制，连接建立
UDP（不可靠），基于“尽力而为”
均不保证延时和带宽
多路复用和分用
为什么复用分用？----如果某层的一个协议直接对应上层的多个协议/实体。则需.
无连接的分用：

UDP的Socket用二元组标识（目的IP,目的端口）主机收到UDP段后检查目的端口，将UDP段到现在个绑定该端口的Socket
面向连接的分用：
TCP的Socket用四元组标识（源IP,源端口，目的IP,目的端口），利用四个值将段导向合适的Socket，服务器可能支持多个TCP Socket，每个用自己的四元组表示。

UDP协议

基于Internet ip协议
提供复用/分用
简单错误校验
为什么要校验？
-----端到端的原则，不能保证下面的所有链路层协议有差错控制，即使都有，路由器存储转发也可能出错。
Best effort 服务，UDP段可能丢失，不按序到达
无连接
不需要握手建立连接
每个UDP段独立于其他段
UDP为什么存在
无需连接，延迟小
实现简单，无需维护连接状态
头部开销小
没有拥塞控制：应用可更好地控制发送时间和速率
常用于:
流媒体应用
容忍丢失
速率敏感
DNS
SNMP
6）可靠性由应用层提供
UDP报文格式

校验和：检测传输过程中是否发生错误

TCP协议

特点
1）点对点
2）可靠、按序字节流
3）流水线机制：TCP拥塞控制和流量控制机制设置窗口尺寸，介于GBN和SR
4）接收方/发送方缓存
5）全双工，数据双向流动
6）面向链接
TCP结构：
1）序列号：段的第一个字节的编号，不是segment的编号。
2）ACks:希望接收的下一个字节序号，累积确认机制（GBN也是），该序列号以前的下、都被正确接收
3）乱序帧怎么处理？
---------TCP规范并没有约定，实现者自己决定
TCP可靠数据传输
1）流水线机制：发送多个分组
2）累积确认
3）单一重传计时器
4）触发重传事件：超时，收到重复ACK
TCP RTT 和超时
1）如何设定时器的超时时间？
大于RTT，RTT本身变化
2）如何估计RTT?
SampleRTT:测量从段发出去到收到ACK的时间（忽略重传）
SampleRTT的变化：多测量，求平均值EstimatedRTT
EstimatedRTT（new）=(1-a)EstimatedRTT（old）+aSampleRTT（实际测量）
a=0.125
超时定时器的设置：
EstimatedRTT+“安全边界”
如果EstimatedRTT变化大—>则较大的边界
测量RTT变化值：SampleRTT与EstimatedRTT的差值
DevRTT=(1-b)DevRTT+b|SampleRTT-EstimatedRTT| b=0.25
定时器超时时间的设置：TimeoutInterval=-EstimatedRTT+4*DevRTT
TCP发送方事件：

从应用层收到数据
创建Segment
开启计时器
设置超时时间
超时
重传引起超时的Segment
重启计时器
收到ACK
如果是确认此前没有确认的Segment
更新SendBase
如果窗口里还有未被确认的分组，重新启动定时器
快速重传机制：
如果sender收到同一数据的三个ACK，则假定该数据之后的段已经丢失
快速重传：定时器超时前重传

TCP流量控制机制：
接收方为TCP连接分配缓存
上层应用处理缓存数据可能慢，但是发送方的发送太块。以至于淹没接收方（缓存溢出）。 Receiver通过RcvWindow告诉Sender
Sender限制自己已经发送的但是还未收到的ACK的数据不超过接收方空闲RcvWindow的尺寸
RcvWindow=0，Sender停止发送
TCP连接管理
1）TCP Sender和Receiver在数据传输前要建立连接
2）要初始化TCP变量：seq,buffer和流量控制信息
3）Client:链接的发起者
4）Server:等待客户连接请求
5）三次握手：Client:TCP SYN(初始化seq no data)—>Server:SYN ACK (分配缓存，初始化seq，确认client段)---->Client:SYN ACK（SYN不再是1，可以含有data）

7）关闭TCP连接
客户机服务器都可以发起
过程：Client/Server：FIN
Sever:ACK(客户不可发数据)
Server:FIN
Client:ACK（WAIT，如果重复收到Server的FIN,则会重发ACK，直到Server收到ACK）

等待2MSL才客户端关闭的原因：

统计Linux下的各种状态下链接数目
netstat命令
netstat -lntup
说明： l:listening n:num t:tcp u:udp p:process
统计机器中网络连接各个状态个数
netstat -an | awk '/^tcp/ {++S[$NF]} END {for (a in S) print a,S[a]} ’
拥塞控制原理：
1）拥塞：“太多主机发送了太多的数据或者发送速度太快，以至于网络无法处理。”
2）表现：分组丢失（路由器缓存溢出），分组延迟过大（路由器缓存排队）
3）拥塞控制（整个网络着眼）VS流量控制(着眼发送方与接收方 )
4）top-10 problem
23.拥塞控制方法
1）端到端拥塞控制如TCP：端系统通过观察loss,delay判断，网路层不提供支持
2）网络辅助拥塞控制：路由器发送显示地反馈网络拥塞信息；简单的拥塞指示（1bit）；指示发送方的发送速率
3）ATM 的ABR拥塞控制（网络辅助拥塞控制）
.TCP拥塞控制：
TCP拥塞控制

原理：逐渐增加发送速率，直到发生loss
方法：AIMD（拥塞避免）—加性增，乘性减
- 每个RTT将CongWin增大一个MSS
- 发生loss以后将CongWin减半
SS（慢启动）
TCP建立时 CongWin=1
可用带宽可能远高于初始速率，希望快速增长
原理：连接开始时，CongWin指数增长—>
每个RTT，CongWin翻倍
收到每个ACK进行操作
初始速率慢，但是快速攀升
何时指数型增长切换为线性增长？
当CongWin达到loss事件前值的1/2时。
实现方法：Threshold
Loss事件发生时，Threshold被设置为Loss事件前CongWin值的1/2
Loss事件的处理：
- 3个重复ACK：CongWin减半，线性增长
- Timeout：CongWin直接设为1MSS，然后指数增长，达到Threshold后，再线性增长
总结：
1.当CongWin<Threshold，发送方慢启动，窗口指数增长
2.当CongWin>Threshold，发送方拥塞避免，窗口线性增长
3.发生拥塞：如果是重复ACK，Threshold置为CongWin/2，CongWin置为Threshold；如果是timeout，Threshold置为CongWin/2，CongWin置为1MSS

TCP与UDP区别
TCP UDP
连接非链接
可靠不可靠
有序无序
慢快
重量级轻量级
Socket

HTTP

特点
HTTP是Hypertext Transfer Protocol的缩写，即超文本传输协议。顾名思义，HTTP提供了访问超文本信息的功能，是WWW浏览器和WWW服务器之间的应用层通信协议。
网页包含多个对象：
对象：html文件，图片、视频、动态脚本；基本html
基本html文件：包含对其他对象的引用
对象寻址：URL,统一资源定位器
Scheme://host:port/path
web(万维网）应用使用HTTP协议
HTTP协议：

C/S结构:客户–浏览器，请求，接收、展示web对象，服务器，web server,响应客户请求，发送对象
HTTP版本：1.0和1.1
使用tcp传输协议:
无状态协议：服务器不维护客户端过去所发的请求的信息，（有状态的协议更加复杂，维护历史信息，可能产生状态不一致）

HTTP分为：
非持久连接：每次TCp连接最多允许传输一个对象。HTTP1.0
持久连接:每次TCp连接允许传输多个对象，HTTP/1.1
****RTT:发送到返回的时间
- 非持久连接响应时间：
  1.建立TCP链接，1RTT
  2.发送HTTP请求：消息到HTTP响应消息的前几个字节到达：1Rtt
  3.响应所含文件/对象的传输时间
  total=2RTT+文件发送时间
- 非持久连接问题：
  每个对象需要>2RTT
  操作系统为每个TCP连接开销资源
  浏览器会打开多个并行Tcp连接以获取网页，但是服务器造成很大负担
- 持久连接：
  发送响应后，服务器保持TCP连接
  后续HTTP消息可以通过这个连接发送
- 持久连接分为：
  - 无流水的持久连接：
    客户端只有收到前一个响应后才发送新请求
    每个新被引用的对象耗时1个RTT,省去了一个建立TCP连接的时间
  - 带有流水机制的持久性连接:
    HTTP1.1默认选项
    客户端只要遇到一个引用对象就尽快发送请求
    理想下，收到所有的引用对象只要一个RTT（一次RTT建立tcp连接，请求html文件，一个RTT,剩余所有的对象，一个RTT,功3个RTT）
补充：
1. 客户端请求1个基本HTML文件，要耗时2个RTT(round trip time)。
2. “三次握手”时，客户向服务器发送连接请求，服务器发送确认。
  3… “三次握手”时，客户向服务器发送确认，并携带请求消息，服务器发送响应消息。
请求消息与应答消息：
1）post:用户输入消息会放在HTTP请求的消息体中上传
2）get:输入小徐通过request行的URL字段携带
3）HTTP请求消息：
HTTP/1.0的请求消息类型
get
post
head：（请服务器不要将所亲求的对象放入响应消息里）
HTTP/1.1的请求消息类型
GET
POST
HEAD
PUT:把消息体里的文件上传到url字段所指定发的路径
DELETE：删除url字段所指定的文件
HTTP响应消息
HTTP
SMTP\pop\imap
dns