分层的目的：

  1. 每一层都是相对独立的功能，降低系统复杂度
  2. 各层之间界面清晰，易于理解，相互交流尽可能少
  3. 保持上层对下层的独立性，上层单向使用下层服务
  4. 促进标准化工作

OSI模型

物理层

  • 传输比特

    链路层

    传输帧，将网络层发送来的IP数据包封装成帧。
    将物理层提供的可能出错的物理连接改成逻辑上无差错的数据链路，使之对网络层表现为一个无差错的链路。
    将源机器中来自网络层的数据传输到目标机器的网络层。

SDLC
HDLC：高级数据链路控制（High-Level Data Link Control或简称HDLC）
PPP：Point-to-Point Protocol，缩写：PPP
STP
CSMA/CD：

  • Carrier Sense Multiple Access，缩写：CSMA
  • 非持续CSMA（英语：non-persistent CSMA）当要发送帧的设备侦听到线路忙或发生碰撞时，会随机等待一段时间再进行发送；此策略可以减少碰撞，但会导致信道利用率降低，以及较长的延迟。
  • 1-持续CSMA（英语：1-persistent CSMA）当要发送帧的设备侦听到线路忙或发生碰撞时，会持续侦听；若发现不忙则立即发送。当传播延迟较长或多个设备同时发送帧的可能性较大时，此策略会导致较多的碰撞，导致性能降低。
  • p-持续CSMA（英语：p-persistent CSMA）当要发送帧的设备侦听到线路忙或发生碰撞时，会持续侦听；若发现不忙，则根据一个事先指定的概率p来决定是发送帧还是继续侦听（以p的概率发送，1-p的概率继续侦听）；此种策略可以达到一定的平衡，但对于参数p的配置会涉及比较复杂的考量。正确使用以上策略可以在一定程度上减少碰撞的发生，但无法彻底解决碰撞问题。
  • 载波侦听多路访问／碰撞检测（CSMA/CD）
    • 先听后发
    • 边听边发
    • 冲突停发
    • 随机重发

网络层

传输数据报
目的：将网络层协议数据单元分组从源传到目的主机

  • 路由选择

协议

  • IP
  • ICMP：
    • 互联网控制消息协议（英语：Internet Control Message Protocol，缩写：ICMP）
    • 用于告知网络包在传输过程中产生的错误以及各种控制消息
    • ping 和 traceroute 这两个特别的例子
  • IGMP：
    • 网路群组管理协议（英语：Internet Group Management Protocol，缩写：IGMP）
    • 管理网路协议多播组成员的一种通信协议。

  • ARP：

    • 地址解析协议（英语：Address Resolution Protocol，缩写：ARP）
    • ARP是通过网络地址来定位MAC地址。
    • 1.当发送数据时，主机A会在自己的ARP缓存表中寻找是否有目标IP地址。如果找到就知道目标MAC地址为（00-BB-00-62-C2-02），直接把目标MAC地址写入帧里面发送就可。
    • 2.如果在ARP缓存表中没有找到相对应的IP地址，主机A就会在网络上发送一个**广播**（ARP request），目标MAC地址是“FF.FF.FF.FF.FF.FF”，这表示向同一网段内的所有主机发出这样的询问：“192.168.38.11的MAC地址是什么？”
    • 3.网络上其他主机并不响应ARP询问，只有主机B接收到这个帧时，才向主机A做出这样的回应（ARP response）：“192.168.38.11的MAC地址是00-BB-00-62-C2-02”，此回应以单播方式。这样，主机A就知道主机B的MAC地址，它就可以向主机B发送信息。同时它还更新自己的ARP高速缓存（ARP cache），下次再向主机B发送信息时，直接从ARP缓存表里查找就可。

  • RARP

  • OSPF：

    • 开放式最短路径优先（英语：Open Shortest Path First，缩写为 OSPF）
    • IGP协议。
    • 迪杰斯特拉算法

    • 传输层

      传输报文段（TCP）或者用户数据报（UDP）
      端到端的通信，两个进程之间

  • 流量控制

  • 差错控制

协议

  • TCP
  • UDP

    会话层

    使不同主机的各个进程实现会话
    建立同步SYN

表示层

处理两个系统之间交换信息的表示方式

  • 编码
  • 压缩
  • 加密
  • 解密

    应用层

    FTP
    SMTP
    HTTP

TCP/IP模型

网络接口层

从主机或者节点接受IP分组，并将它们发送到指定的物理网络

网际层（关键）

  • 路由
  • 不保证有序，有序交给高层负责
  • 面向无连接

协议

  • IP

传输层

使得发送端和目的端主机上的对等实体进行对话。

  • 传输控制协议TCP
    • 面向连接
    • 单位：报文段
    • 可靠交付

  • 用户数据包协议UDP

    • 无连接
    • 单位:用户数据报
    • 尽最大努力交付

      应用层

  • Telnet

  • FTP
  • HTPP
  • SMTP
  • DNS

数据链路层

MAC帧最小64B。
MAC地址6B，48位
传输帧，将网络层发送来的IP数据包封装成帧。
将物理层提供的可能出错的物理连接改成逻辑上无差错的数据链路，使之对网络层表现为一个无差错的链路。
将源机器中来自网络层的数据传输到目标机器的网络层。

多帧滑动窗口的后退N帧协议：GBN

  • 发送方无须收到上一个帧的ACK后才能开始发送下一帧，而是可以连续发送帧。
  • 接收方检测到失序，要求发送方重发最后一个正确接收的帧之后所有未被确认的帧
  • 当发送方发送了N个帧后，若发现该N个帧的前一个帧在计时器超时后依旧没有确认，则出错，重传从这个帧开始的帧
  • 接收方只按顺序接收帧

多帧滑动窗口与选择重传协议SR

  • 给每个发送缓冲区一个计时器，计时器超时，缓冲区的帧就会重传。
  • 接收方不能接收接收窗口下界以下或者上届以上的帧
  • 一个帧出错的时候，只需要重传出错的帧

CSMA
信道空闲，立即发送；信道忙，等待同时监听直到信道空闲立刻发送；冲突则随机等待一个时间在重新监听

CSMA/CD
载波监听多路访问/碰撞检测

先听后发，边听边发，冲突停发，随机重发

  • 半双工
  • 指数退避算法

PPP协议：

  • 串行
  • 面型字节
  • 直接连接在两个节点的链路上

HDLC：
高级数据链路控制

  • 面向比特

网络层

如果主机号部分全部为0，则代表是一个子网
如果主机号部分全部为1，则代表是广播

路由器

  • 路由选择
    • 距离向量算法RIP
      • 所有节点都定期的将他们的整个路有选择表传给所有与之直接相邻的节点
      • 路由表包括:每个路径的目的地+距离
    • 链路状态算法OSPF
      • 每个节点都具有完全的网络拓扑信息
      • 主动测试所有邻接节点的状态+定期将链路状态传播给所有其他节点
      • Dijsktra算法
        1. 通过Dijkstra计算图G中的最短路径时，需要指定起点s(即从顶点s开始计算)。
        2. 此外，引进两个集合S和U。S的作用是记录已求出最短路径的顶点(以及相应的最短路径长度)，而U则是记录还未求出最短路径的顶点(以及该顶点到起点s的距离)。
        3. 初始时，S中只有起点s；U中是除s之外的顶点，并且U中顶点的路径是”起点s到该顶点的路径”。然后，从U中找出路径最短的顶点，并将其加入到S中；接着，更新U中的顶点和顶点对应的路径。 然后，再从U中找出路径最短的顶点，并将其加入到S中；接着，更新U中的顶点和顶点对应的路径。 … 重复该操作，直到遍历完所有顶点。
        4. 分层 - 图1
    • 层次路由
      • 自治系统的内部网关协议IGP:RIP+OSPF
      • 外部网关协议EGP
  • 分组转发
  1. ipv4首部长20B
  • NAT(传输层,因为看到了端口) 网络地址转换协议
    • 专用网络地址转换为公网地址
      • 192.168/172.16-172.31/10.
      • 存放了{本地ip地址:端口}到{全球ip地址:端口}
  • 子网划分CIDR:减小广播域大小
    • 可以路由聚合,实现超网
    • 最长前缀匹配
  • ARP(网络层)
    • ip地址->硬件地址MAC
    • 主机A不知道主机B流程
      • 先查看A的ARP高速缓存有没有主机B的ip地址
        • 有:查出对应的mac,将此mac写入mac帧,然后通过局域网发送给这个硬件地址
        • 没有就想目的mac写入全F发送ARP请求,一个局域网所有主机收到请求,主机B发出响应ARP,A收到后写入自己的ARP缓存
  • DHCP(应用层,基于UDP)动态主机配置协议
    • 给主机动态的分配ip地址
    • 客户/服务器模式
    • 客户端发送发现报文
    • 只有服务器才回答客户端,服务器发出的称为提供报文
      • 客户端广播发送”DHCP发现”消息
      • 服务器广播发送”HDCP提供”消息
      • 客户端广播发送”DHCP请求”消息
      • 服务器广播发送”DHCP确认”消息
  • ICMP网际控制报文协议(网络层)
    • 让主机或者路由器报告差错或者异常情况
    • 差错报文
    • 询问报文
    • ping/traceroute

ipv6:

  • 地址128bit
  • ipv4是4字节,ipv6是16字节
  • 自动配置
  • 不允许分片
  • 过渡
    • 隧道
    • 双协议栈

  • RIP(应用层,使用UDP) 路由信息协议,距离向量

    • 和相邻的路由器交换信息
    • 最开始每个路由器只知道与自己直接相连的网络,然后30s一次RIP广播,相邻的路由器就知道了与自己相邻的路由器(跳数为1)的路由表,然后30s第二次广播,知道了跳数为2的路由器路由表…..然后最终所有路由器都知道了整个ip网络的路由表,最终rip成为收敛的
      • 对X发来的路由表,将其所有的项目下一条改成X,距离+1
        • 如果没有N的地址,把项目添加到路由表
        • 有N,并且下一条是X,按新的来更新
        • 有N,下一条不是X,并且距离小于原来的,更新
    • 180s无反应,设置为不可达

    • 返回

    • 开销小,简单,收敛快

    • 但是规模小
    • 慢收敛
      • 坏消息穿的慢

  • OSPF(开放最短路径优先,网络层)

    • 向所有路由器发送信息
    • 发送与本路由器相连的所有路由器的链路状态
    • 链路变化的时候,才洪范发送
  • 灵活
  • 负载均衡
  • 全网保持一个拓扑
  • BGP(应用层,TCP)
    • 找到一个比较好的路由
    • 而不是最佳的
    • 路径向量

传输层

  • 两个进程之前的通信
  • 端口号
    • FTP 21
    • SSH 22
    • TELNET 23
    • SMTP 25
    • DNS 53
    • TFTP 小文件传输协议 69
    • HTTP 80
    • https 443
    • SNMP 161
  • 套接字=(ip地址,端口号)

TCP首部20B
UDP首部8B
**

UDP

  • 无需建立连接
  • 无连接状态
  • 首部开销小 8B
  • 没有拥塞控制
  • 适合一次性传输较小数据的网络应用,例如dns
  • 报文不可分割

分层 - 图2

TCP

  • 字节流
  • 面向连接,可靠
  • 全双工
  • 首部20B

分层 - 图3

三次握手

分层 - 图4
客户机发送请求TCP报文syn=1,seq=x,可以不带数据,但是消耗一个序号
服务器发送确认:syn=1,ACK=1,ack=x+1,seq=y 不携带数据,消耗一个序号
客户端发送确认:ACK=1,seq=x+1,ack=y+1ACK报文段可以携带数据，但是如果不携带数据则不消耗序号
image.png

三次握手过程中可以携带数据么？

第三次握手的时候，可以携带。前两次握手不能携带数据。
如果前两次握手能够携带数据，那么一旦有人想攻击服务器，那么他只需要在第一次握手中的 SYN 报文中放大量数据，那么服务器势必会消耗更多的时间和内存空间去处理这些数据，增大了服务器被攻击的风险。

连接建立后,ACK必须都是1

  • 为什么进行第三次确认?
  • 如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个**请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接**。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
    • 第一次握手：

    Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

    • 第二次握手：

    Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

    • 第三次握手：

    Client 确认了：自己发送、接收正常，对方发送、接收正常； Server 确认了：自己发送+接收正常，对方发送+接收正常 所以三次握手就能确认双发收发功能都正常，缺一不可。

  • TCP三次握手中第三次握手失败了怎么办？是否会重发？重发次数多少？
    • Server 端

第三次的ACK在网络中丢失，那么Server 端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5.
如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接。

  • Client 端

在linux c 中，client 一般是通过 connect() 函数来连接服务器的，而connect()是在 TCP的三次握手的第二次握手完成后就成功返回值。
也就是说 client 在接收到 SYN+ACK包，它的TCP连接状态就为 established （已连接），表示该连接已经建立。那么如果第三次握手中的ACK包丢失的情况下，Client向server端发送数据，Server端将以 RST包响应，方能感知到Server的错误。

四次挥手

image.png
**
FIN=1,seq=u
ACK=1,seq=v,ack=u+1
FIN=1,ACK=1,seq=w,ack=u+1
ACK=1,seq=u+1,ack=w+1

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。把确认和连接放到了一次握手中。 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP可靠性

使用校验,序号,确认,重传进行控制.

  1. 序号
    1. 保证数据能有序的交给应用层
  2. 确认
    1. TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号
    2. 采用累计确认
      1. 只确认第一个丢失字节为止的字节
  3. 重传
    1. 超时
      1. 发送一个报文段就设置一个计时器,如果超出计时器的时间还没有收到确认,就需要重传这个报文段
    2. 冗余ACK
      1. 冗余ACK就是再次确认某个报文段的ACK,而发送方先前已经收到该报文的确认
      2. 1,2,3,4,5如果2丢失了,那么3,4,5就成了失序报文段,每收到一个比期望值大的序号的报文段的时候,就发送一个冗余ACK,指名下一个期望的报文段.
      3. 如果收到了同一报文段的冗余ACK,就重传(即快速重传)

流量控制

  • 两个端之间的
  • 消除发送方使接收方缓存溢出的可能性

  • 两台主机之间的

  • 基于滑动窗口

接收方根据自己缓存的大小,动态调整发送方的发送窗口的大小;接收方根据这个值动态的调整自己发送窗口的大小.
接收方的是接收窗口,发送方的是发送窗口.

  1. 停止等待协议：发送窗口=1，接收窗口=1
  2. 后退N帧协议：发送窗口>1，接收窗口=1
    1. 接受方只允许顺序接受帧
  3. 选择重传协议：发送窗口>1，接受窗口>1

发送方根据当前网络拥塞程度的估计确定的窗口值叫做拥塞窗口.

拥塞控制

  • 全局性的
  • 对应的是拥塞窗口

与流量控制的区别:
拥塞控制是让网络可以承受现有的负载,是一个全局性的过程;
流量控制是点对点的通信量的控制,即接收端控制发送端.

慢开始的目的：
刚开始进入传输数据的时候，你是不知道现在的网路到底是稳定还是拥堵的，如果做的太激进，发包太急，那么疯狂丢包，造成雪崩式的网络灾难。
因此，拥塞控制首先就是要采用一种保守的算法来慢慢地适应整个网路，这种算法叫慢启动。
慢开始:

  1. 刚开始连接发送tcp报文段的时候,让拥塞窗口=1个最大报文段的长度MSS,每收到一个确认的时候,将拥塞窗口+1
  2. 没经过一个轮次(往返时延),拥塞窗口就会加倍
  3. 然后到达一个设定的门限,开始改用拥塞避免算法

拥塞避免

  1. 发送端拥塞窗口每经过一个往返时延就增加一个单位,而不是加倍,使其线性增长
  2. 当出现一次超时的时候(网络拥堵),令慢开始的门限等于当前拥塞窗口的一半
  3. 重新慢开始

快重传
发送方连续收到三个冗余ACK的时候,直接重传对方没有收到的报文段,而不必等待那个报文段设计的计时器超时

快恢复
连续收到三个冗余ACK的时候,把慢开始的门限设置为拥塞窗口的一半,并直接把拥塞窗口设置为慢开始的门限,避免了拥塞窗口从1开始增大的过程

  • 发送方检测到超时:慢开始+拥塞避免
  • 检测到冗余ACK:快重传+快恢复

发送方的发送窗口由:流量控制+拥塞控制共同控制

应用层

应用模型:
客服端/服务器模型
P2p模型:两个对等方直接连接

  • 减轻了服务器的压力
  • 扩展性好
  • 健壮

DNS

  • 域名系统,53端口
  • udp
  • 将域名映射为IP地址
  • 根域名服务器
    • 顶级域名服务器
      • 权限域名服务器
        • 本地域名服务器
  • 解析过程
    • 本机dns客户端构造一个dns请求报文,以udp的方式发往本地域名服务器
    • 递归查询(给根域名服务器压力过大)
    • 递归+迭代查询
      • 主机向本地域名服务器使用的是递归查询
        • image.png
      • 本地域名服务器向跟域名服务器使用的是迭代查询
        • image.png

获得y.abc.com的过程

  1. 客户机向本地域名服务器发出DNS请求报文
  2. 本地域名服务器收到请求,查询本地缓存,如果没有记录,以DNS客户的身份向根域名服务器发送解析请求
  3. 根域名服务器根据.com,将对应的顶级域名服务器的ip地址返回给本地域名服务器
  4. 本地域名服务器向顶级域名服务器发出解析请求
  5. 顶级域名服务器根据abc.com,判断出这是哪个授权域名服务器的域,返回对应的服务器ip地址
  6. 本地域名服务器又发起请求
  7. 对应的域名服务器把ip地址发送回来
  8. 本地域名服务器把结果缓存,同时返回给客户机

电子邮件

  • 异步的
  • SMTP推:发送发->发送方邮件服务器;发送方服务器->接收方服务器
  • POP拉:接收方服务器->接受方

HTTP

  • 两大报文
    • 请求报文
    • 响应报文

访问清华大学网站的流程

  1. 浏览器分析连接指向的页面URL
  2. 浏览器向DNS请求解析这个地址
  3. 域名DNS系统解析出来www.tsinghua.com的ip地址
  4. 浏览器与该服务器建立连接(三次握手)
  5. 浏览器发送http请求
  6. 服务器响应http请求
  7. tcp连接释放(四次挥手)
  8. 浏览器解析网页,现实给用户
  • 非持久连接
    • 每个网页请求元素对象传输都单独建立一个tcp连接
  • 持久连接http1.1
    • 同一个服务器和客户在连接建立以后,可以多次进行http请求与响应
      • 流水线模式(默认)
        • 用户每遇到一个对象请求立即发出请求
      • 非流水线
        • 客户在接受到前一个的相应之后,才能发出下一个请求

WebSocket

WebSocket是一种网络传输协议，可在单个TCP连接上进行全双工通信，位于OSI模型的应用层。

WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。

在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。

http2.0 1.1

HTTP1.1新改动：

  • 持久连接
    • 建立一次连接，多次请求均由这个连接完成！
    • 发送一次请求时，不需要等待服务端响应了就可以发送请求了，但是回送数据给客户端的时候，客户端还是需要按照响应的顺序来一一接收
    • 所以说，无论是HTTP1.0还是HTTP1.1提出了Pipelining理论，还是会出现阻塞的情况。从专业的名词上说这种情况，叫做线头阻塞（Head of line blocking）简称：HOLB
  • 请求管道化
  • 增加缓存处理（新的字段如cache-control）
  • 增加Host字段、支持断点传输等

HTTP2新改动：

  • 二进制分帧
  • 多路复用
    • 允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息
  • 头部压缩
  • 服务器推送

缓存

HTTP HTTPS

Http与Https的区别：

HTTP 的URL 以http://开头，而HTTPS 的URL 以https:// 开头
HTTP 是不安全的，而 HTTPS 是安全的
HTTP 标准端口是80 ，而 HTTPS 的标准端口是443
在OSI 网络模型中，HTTP工作于应用层，而HTTPS 的安全传输机制工作在传输层
HTTP 无法加密，而HTTPS 对传输的数据进行加密
HTTP无需证书，而HTTPS 需要CA机构颁发的SSL证书

完整的HTTPS的步骤

  • 建立TCP连接

在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建 Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则， 只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。

  • Web浏览器向Web服务器发送请求行

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。

  • Web浏览器发送请求头
    • 浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
  • Web服务器应答
    • 客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
  • Web服务器发送应答头
    • 正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
  • Web服务器向浏览器发送数据
    • Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
  • Web服务器关闭TCP连接
    • 一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码：

Connection:keep-alive
TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。
建立TCP连接->发送请求行->发送请求头->（到达服务器）发送状态行->发送响应头->发送响应数据->断TCP连接

URL URI

URI，是uniform resource identifier，统一资源标识符，用来唯一的**标识**一个资源。

  • Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
  • URI一般由三部组成：
  • ①访问资源的命名机制
  • ②存放资源的主机名
  • ③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源**定位**器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

  • URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
  • 采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
  • ①协议(或称为服务方式)
  • ②存有该资源的主机IP地址(有时也包括端口号)
  • ③主机资源的具体地址。如目录和文件名等

作者：denight 链接：https://www.zhihu.com/question/21950864/answer/154309494 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来。 拿人做例子，假设这个世界上所有人的名字都不能重复，那么名字就是URI的一个实例，通过名字这个字符串就可以标识出唯一的一个人。 现实当中名字当然是会重复的，所以身份证号才是URI，通过身份证号能让我们能且仅能确定一个人。 那统一资源定位符URL是什么呢。也拿人做例子然后跟HTTP的URL做类比，就可以有： 动物住址协议://地球/中国/浙江省/杭州市/西湖区/某大学/14号宿舍楼/525号寝/张三.人 可以看到，这个字符串同样标识出了唯一的一个人，起到了URI的作用，所以URL是URI的子集。URL是以描述人的位置来唯一确定一个人的。 在上文我们用身份证号也可以唯一确定一个人。对于这个在杭州的张三，我们也可以用： 身份证号：123456789 来标识他。 所以不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。 回到Web上，假设所有的Html文档都有唯一的编号，记作html:xxxxx，xxxxx是一串数字，即Html文档的身份证号码，这个能唯一标识一个Html文档，那么这个号码就是一个URI。 而URL则通过描述是哪个主机上哪个路径上的文件来唯一确定一个资源，也就是定位的方式来实现的URI。 对于现在网址我更倾向于叫它URL，毕竟它提供了资源的位置信息，如果有一天网址通过号码来标识变成了http://741236985.html，那感觉叫成URI更为合适，不过这样子的话还得想办法找到这个资源咯…