网络基础知识

计算机诞生

SEROTON.png

“第一台计算机(ENIAC)于1946年2月,在美国诞生。提出程序存储的是美国的数学家冯^诺依曼, 在美国陆军部的资助下，与1943年开始了ENIAC的研制，1946年完成。”

世界上第一台通用计算机“ENIAC”于1946年2月14日在美国宾夕法尼亚大学诞生。发明人是美国人莫克利（JohnW.Mauchly）和艾克特（J.PresperEckert）。 [1]

美国国防部用它来进行弹道计算。它是一个庞然大物，用了18000个电子管，占地170平方米，重达30吨，耗电功率约150千瓦，每秒钟可进行5000次运算，这在现在看来微不足道，但在当时却是破天荒的。 ENIAC以电子管作为元器件，所以又被称为电子管计算机，是计算机的第一代。电子管计算机由于使用的电子管体积很大，耗电量大，易发热，因而工作的时间不能太长。

ENIAC，世界上第一台电子计算机，占地170平方米，重达30吨，耗电功率约150千瓦每时，每秒钟可进行5000次运算。被美国国防部用来进行弹道计算。

总结：1946年情人节那天计算机诞生于美国，被应用于军事 ！

了解：网络通信的前身是电话通信

比如：座机A和座机B通过电话局中转接通电话信号实现通话；后期利用信号塔作为媒介发送无线信号应用于网络

网络通信三要素：IP地址、端口、传输协议

IP地址

• 网络中设备的标识
• 不易记忆，可以用主机名

• 本地回环地址:127.0.0.1 主机名：localhost
  IP地址：即主机地址，IP地址类型可以分为ipv4和ipv6, ip地址由4段数字表示每段数字范围在0~255之间
  本机IP：每个电子计算机设备都有一个固定的IP—>127.0.0.1；这个IP是计算机本地回环地址， 也被称之为locahost 本地主机名 ，可以通过ping 127.0.0.1查看，如果ping不通基本上就是网卡有问题
  内网IP：当设备连接到网络时路由器会分配给每个设备一个IP地址，这个地址就是内网IP；

  
  
  174709@2x.png

如果想知道路由是否连通可以ping 内网IP测试 ：ping192.168.1.7 ，不通可能就是路由这边出的问题
外网IP：外网IP是计算机对外连接的地址，该地址不一定就是路由器的地址，因为路由器可能还连接着其他路由器，这时该路由器自己也在其他的内网中；准确的方法可以通过https://www.ip138.com 查看

174730@2x.png

端口

端口是端口号的一个统称，常见的端口有：80端口、110端口、21端口、443端口

• 80端口用于访问Apache（阿帕奇）网络服务，HTTP请求使用的就是80端口
• 110端口多用于访问电子邮件
• 21端口多用于文件传输
• 443端口用于HTTPS协议

端口号

• 用于标识进程的逻辑地址，不同进程的标识
• 有效端口：0~65535
• 其中0~1024由系统保留使用，开发中不要使用1024以下的端口

142924@2x.png

传输协议

OSI网络模型

175329@2x.png

如上图所示：客户端A发送聊天消息给客户端B一条 “哈哈“ 信息，经过网络七层变为电信号，通过网络传递到客户端B之后再解包获得信息”哈哈”；

网络层：路由器在其所已知的端口中找到(算法)最优路径分配网络传输数据，IP协议就在网络层
数据链路层：用来打包数据，同时会添加校验码用来验证；这种数据的格式是帧格式
物理层：网线
早期的电脑和电脑之间是无法直接传输数据的，需要通过软盘💾传输；类似于今天的硬盘，把一台电脑的数据拷贝到另一台电脑，且当时的软盘存储空间非常的小；由于这种传输方式非常极不方便，就有人提出能不能在两台电脑之间拉一条线来传输数据 ？多数人认为拉什么线 ？疯了吧 ？但是真有人按照这个思路想到了电线，因为电线传输的电流有高低频之分刚好对应计算机的二进制0b010101，只要让数据和电流的频率一致，通过转化不就可以传递数据信息了吗 ？由此就有了网线被发明出来 ！这个过程被称之为数转模！电流在传递过程中会有损耗，会造成数据不准确，这时科学家就发明出来了中继器，由中继器来放大电信号

175357@2x.png

传输层协议TCP/UDP

UDP : 用户数据包协议 ，类似于短信

1. 只管发送，不确认对方是否接收到
2. 将数据源和目的封装成数据包，不需要建立连接
3. 每个数据包的大小限制在64k之内
4. 因为无需连接，因此是不可靠协议
5. 不需要建立连接，传输速度快
6. 应用场景：网络流媒体 比如: 游戏

TCP：传输控制协议

1. 建立连接，形成传输数据的通道
2. 在连接中进行大数据传输（数据大小不受限制）
3. 通过三次握手完成连接，是可靠协议，安全送达
4. 必须建立连接，效率会稍低

UDP开发比较麻烦的点是分包的问题，因为有大小限制在64k之内就需要对数据进行分包；这块会比较麻烦 ！

TCP特点 ：面向连接、可靠传输、面向字节流、全双工服务

• 面向连接：即面向IP地址

• 可靠传输：

1、 网络层服务(IP 服务)是不可靠的。IP 不保证数据报的交付，不保证数据报的交付顺序和完整性。 TCP 则是在 IP 服务上创建了一种可靠数据传输服务
2、 TCP 的可靠数据传输服务确保一个进程从其接收缓存中读出的数据是无损坏、无间隔、无冗余、有序的数据流。即该字节流与连接的另一端发出的字节流是完全相同的。

3、 作为 TCP 接收方，有三个与 发送、重传 有关的主要事件

• 从上层应用数据接收数据

将数据封装到一个报文段中，并把报文段交付给 IP。每个报文段都包含一个序号 Seq，即该报文段第一个数据字节的字节流编号。如果定时器还没有为其他报文段而运行，则启动定时器(即不是每条报文段都会启动一个定时器，而是一共只用一个定时器)，定时器的过期间隔是 TimeoutInterval，是由 EstimatedRTT 和 DevRTT 计算得来的: TCP 的往返时间的估计与超时

• 超时
  TCP 通过重传引起超时的报文段来响应超时事件，然后重启定时器。

而发送端超时有两种情况: 发送数据超时，接收端发送 ACK 超时。这两种情况都会导致发送端在 TimeoutInterval 内接收不到 ACK 确认报文段。

• 如果是发送数据超时，直接重传即可。
• 如果是接收端发送 ACK 超时，这种情况接收端实际上已经接收到发送端的数据了。那么当发送端超时重传时，接收端会丢弃重传的数据，同时再次发送 ACK；而如果在 TimeoutInterval 后接收到了 ACK，会收下 ACK，但不做任何处理 ；
• TCP 不会为没有数据的 ACK 超时重传
  以下两种情况:
• 如果在发送两条或多条数据报文段都超时，那么只会重传序号最小的那个，并重启定时器。只要 其余报文段的 ACK 在新重启的定时器超时前到达，就不会重传。
• 2、如果发送序号为 100 和 120 的两条数据报文段，序号 100 的 ACK 丢失，但收到了序号 120 的 ACK， 由于累积确认机制，可以得出接收方已经接收到了序号 100 的报文段，这种情况也不会去重传。

• 接收到 ACK

• 用 TCP 状态变量 SendBase 指最早未被确认的字节的序号。则 SendBase - 1 指接收方已正确按序接收 到的数据的最后一个字节的序号。当收到 ACK 确认报文段后，会将 ACK 的值 Y 与 SendBase 比较。TCP 采用累计确认的方法，所以 Y 确认来 字节编号在 Y 之前的所有字节都已经收到。如果 Y 比 SendBase 小，不用理会;而如果 Y 比 SendBase 大，则该 ACK 是在确认一个或多个先前未被确认的报文段，因此要更新 SendBase 变量，如果当前还有未被确认的报文段，TCP 还要重启定时器。 通过超时重传，能保证接收到的数据是无损坏、无冗余的数据流，但并不能保证按序。 而通过 TCP 滑动窗口，能够有效保证接收数据有序

面向字节流

流量控制 ：TCP 连接的双方主机都会为该 TCP 连接分配缓存和变量。当该 TCP 连接收到正确、按序的字节后，就将数据放入接收缓存。上层的应用进程会从该缓存中读取数据，但不必是数据一到达就立即读取，因为此时应 用程序可能在做其他事务。而如果应用层读取数据相对缓慢，而发送方发送得太多、太快，发送的数据就 会很容易地使该连接的接收缓存溢出。

所以，TCP 为应用程序提供了流量控制服务(flow-control service)，以消除发送方使接收方缓存溢出的可能性。

流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。 作为全双工协议，TCP 会话的双方都各自维护一个发送窗口和一个接收窗口(receive window)的变量来提 供流量控制。而发送窗口的大小是由对方接收窗口来决定的，接收窗口用于给发送方一个指示--该接收方还有多少可用的缓存空间。

175408@2x.png

拥塞控制

TCP 除了可靠传输服务外，另一个关键部分就是拥塞控制。
TCP 让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。

可能有三个疑问:
1、TCP 发送方如何感知网络拥塞?
2、TCP 发送方如何限制其向连接发送流量的速率?
3、发送方感知到网络拥塞时，采用何种算法来改变其发送速率?

这就是 TCP 的拥塞控制机制。TCP 连接的每一端都是由一个接收缓存、一个发送缓存和几个变量(LastByteRead、 LastByteRcvd、rwnd 等)组成。而运行在发送方的 TCP 拥塞控制机制会跟踪一个额外的变量，即拥塞 窗口 cwnd(congestion window)。它对一个 TCP 发送方能向网络中发送流量的速率进行了限制。 发送方中未被确认的数据量不会超过 cwnd 和 rwnd 的最小值:min(rwnd,cwnd)

1、TCP 发送方如何感知网络拥塞?
冗余 ACK(duplicate ACK): 就是再次确认某个报文段的 ACK，而发送方先前已经收到对该报文段的确认。

冗余 ACK 的产生原因:

1.当接收端接收到失序报文段时，即该报文段序号大于下一个期望的、按序的报文段，检测到数据流 中的间隔，即由报文段丢失，并不会对该报文段确认。TCP 不使用否定确认，所以不能向发送方发送 显式的否定确认，为了使接收方得知这一现象，会对上一个按序字节数据进行重复确认，这也就产生 了一个冗余 ACK。

2.因为发送方经常发送大量的报文段，如果其中一个报文段丢失，可能在定时器过期前，就会收到大 量的冗余 ACK。一旦收到 3 个冗余 ACK(3 个以下很可能是链路层的乱序引起的，无需处理)，说明 在这个已被确认 3 次的报文段之后的报文段已经丢失，TCP 就会执行快速重传，即在该报文段的定时 器过期之前重传丢失的报文段。

将 TCP 发送方的丢包事件定义为: 要么出现超时，要么收到来自接收方的 3 个冗余 ACK。

当出现过度的拥塞时，路由器的缓存会溢出，导致一个数据报被丢弃。丢弃的数据报接着会引起发送方的丢包事件。那么此时，发送方就认为在发送方到接收方的路径上出现了网络拥塞。

2、TCP 发送方如何限制其向连接发送流量的速率?

当出现丢包事件时:应当降低TCP发送方的速率。
当对先前未确认报文段的确认到达时，即接收到非冗余ACK时，应当增加发送方的速率。

3、发送方感知到网络拥塞时，采用何种算法来改变其发送速率?

即 TCP 拥塞控制算法(TCP congestion control algorithm) 包括三个主要部分: 慢启动、拥塞避免、快速恢复，其中快速恢复并非是发送方必须的，慢启动和拥塞避 免则是 TCP 强制要求的 。

拥塞避免

一旦进入拥塞避免状态，cwnd 的值大约是上次遇到拥塞时的值的一半，即距离拥塞并不遥远。因此，TCP 无法每过一个 RTT 就将 cwnd 翻倍。而是每个 RTT 只增加 1MSS，即每收到一个非冗余 ACK，就将 cwnd 增加 1/cwnd。即假如此时 cwnd 为 10MSS，则每收到一个非冗余 ACK，cwnd 就增加 1/10MSS，在 10 个报文段都收 到确认后，拥塞窗口的值就增加了 1MSS。

175417@2x.png

快速恢复

快速恢复是由 3 个冗余 ACK 引起的。在快速恢复中，对引起 TCP 进入快速恢复状态的缺失报文段，对收到的每个冗余 ACK，cwnd 增加 1 个 MSS。 最终，当对丢失报文段的一个 ACK 到达时，TCP 在降低 cwnd 后进入拥塞避免状态。 如果出现超时，和之前一样，即 TCP 发送方将 ssthresh(慢启动阈值)设置为 cwnd/2，并将 cwnd 重 置为 1MSS，重启慢启动 ，快速恢复并非是必须的。TCP 的拥塞控制是:每个 RTT 内 cwnd 线性(加性增)增加 1MSS，然后出现 3 个冗余 ACK 事件时 cwnd 减半(乘性减)，因此 TCP 拥塞控制常被称为加性增，乘性减拥塞控制方式。

DNS

因特网上的主机，可以使用多种方式标识，比如主机名或 IP 地址。

• 一种标识方法就是用它的主机名(hostname)，比如·www.baidu.com、www.google.com、 gaia.cs.umass.edu 等。这方式方便人们记忆和接受，但是这种长度不一、没有规律的字符串路由器并 不方便处理。
• 还有一种方式，就是直接使用定长的、有着清晰层次结构的IP地址，路由器比较热衷于这种方式。 为了折衷这两种方式，我们需要一种能进行主机名到 IP 地址转换的目录服务。这就是*域名系统(Domain Name System，DNS)的主要任务。

DNS 是:
1、一个由分层的 DNS 服务器实现的分布式数据库
2、一个使得主机能够查询分布式数据库的应用层协议

DNS 服务器通常是运行 BIND 软件的 UNIX 机器，DNS 协议运行在 UDP 上，使用 53 号端口；
DNS 通常是由其他应用层协议所使用的，包括 HTTP、SMTP 等。其作用则是: 将用户提供的主机名解析为 IP 地址

DNS 的一种简单设计就是在因特网上只使用一个 DNS 服务器，该服务器包含所有的映射。很明显这种设计 是有很大的问题的:

单点故障: 如果该 DNS 服务器崩溃，全世界的网络随之瘫痪
通信容量: 单个 DNS 服务器必须处理所有 DNS 查询
远距离的集中式数据库: 单个 DNS 服务器必须面对所有用户，距离过远会有严重的时延。 维护:该数据库过于庞大，还需要对新添加的主机频繁更新。

所以，DNS 被设计成了一个分布式、层次数据库

DNS 服务器
为了处理扩展性问题，DNS 使用了大量的 DNS 服务器，它们以层次方式组织，并且分布在全世界范围内。

域名服务器是提供域名解析的服务器，在有基本的知识下，任何人都可以搭建域名服务器，甚至是根域名 服务器，有名的软件有:BIND

目前的 DNS 服务器大致分为 3 种类型的 DNS 服务器:根 DNS 服务器、顶级域 DNS 服务器、权威 DNS 服务 器

DNS 解析过程

DNS解析.png

很清晰地显示出了一条 DNS 查询链: 本地 DNS 服务器-->根 DNS 服务器-->顶级域 DNS 服务器-->权威 DNS 服 务器 ，所有查询都是递归查询。

175437@2x.png

这种利用了迭代查询和递归查询，从 Client 与本地 DNS 之间是递归查询，其余则是迭代查询。所谓 递归查询过程 就是 “查询的递交者” 更替, 而 迭代查询过程 则是 “查询的递交者”不变。
从理论上讲，任何 DNS 查询既可以是迭代的也能是递归的。而在实际过程中，更常用的是图上 从请求主机到本地 DNS 服务器的查询是递归，其余查询是迭代的这种方式。

DNS 缓存

DNS 缓存(DNS Caching):为了改善时延性能并减少在因特网上到处传输的 DNS 报文数量，DNS 广泛使用 了缓存技术。
有 DNS 的地方，就有缓存。浏览器、操作系统、本地 DNS 服务器、根 DNS 服务器，它们都会 对 DNS 结果做一定程度的缓存。

DNS 解析安全问题

1、DNS 劫持

• 一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的本地 DNS 服务器进行篡改，指向黑客自 己伪造的本地 DNS 服务器，进而通过控制本地 DNS 服务器的逻辑返回错误的 IP 信息进行域名劫持。 另一方面，由于 DNS 解析主要是基于 UDP 协议，除了上述攻击行为外，攻击者还可以监听终端用户的域名 解析请求，并在本地 DNS 服务器返回正确结果之前将伪造的 DNS 解析响应传递给终端用户，进而控制终端 用户的域名访问行为。

175447@2x.png

2、缓存污染(DNS 污染)

我们知道在接收到域名解析请求时，本地 DNS 服务器首先会查找缓存，如果缓存命中就会直接返回缓存结 果，不再进行递归 DNS 查询。这时候如果本地 DNS 服务器针对部分域名的缓存进行更改，比如将缓存结果 指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上。

3、如何解决 DNS 劫持?

DNS 解析发生在 HTTP 协议之前，DNS 解析、DNS 劫持 跟 HTTP 没有关系，DNS 协议使用的是 UDP 协议向服 务器的 53 端口进行请求。要想解决 DNS 劫持:

1. 可以使用 HttpDNS 的方案: 使用 HTTP 协议向 DNS 服务器的 80 端口进行请求,来规避 DNS 劫持 比如:http://119.29.29.29/d?dn=domain&ip=clientIp
2. 在终端上，可以更换DNS服务器，不管手机还是电脑，都能手动配置DNS

Cookie 和 Session

HTTP 协议是无状态、无连接的，服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去 请求服务器；基于 HTTP 这种特点，就产生了 cookie/session

1、用户与服务器的交互:Cookie
cookie 主要是用来记录用户状态，区分用户，状态保存在客户端。

175505@2x.png

• 1.首次访问 amazon 时，客户端发送一个 HTTP 请求到服务器端 。服务器端发送一个 HTTP 响应到客 户端，其中包含 Set-Cookie 头部

• 2.客户端发送一个 HTTP 请求到服务器端，其中包含 Cookie 头部。服务器端发送一个 HTTP 响应到客 户端

• 3.隔段时间再去访问时，客户端会直接发包含 Cookie 头部的 HTTP 请求。服务器端发送一个 HTTP 响 应到客户端

• cookie 技术有 4 个组件:

  • 1. 在 HTTP 响应报文中的一个 cookie 首部行
  • 2. 在 HTTP 请求报文中的一个 cookie 首部行
  • 3. 在用户端系统中保留一个 cookie 文件，并由用户的浏览器进行管理
  • 4. 位于 Web 站点的一个后端数据库 也就是说，cookie 功能需要浏览器的支持。如果浏览器不支持 cookie(如大部分手机中的浏览器)或 者把 cookie 禁用了，cookie 功能就会失效。

2、cookie 的修改和删除

• 在修改 cookie 的时候，只需要新 cookie 覆盖旧 cookie 即可，在覆盖的时候，由于 Cookie 具有不可跨域名性，注意 name、path、domain 需与原 cookie 一致 删除cookie也一样，设置cookie的过期时间expires为过去的一个时间点，或者maxAge=0(Cookie 的有效期,单位为秒)即可
  3、cookie 的安全

• 事实上，cookie 的使用存在争议，因为它被认为是对用户隐私的一种侵害，而且 cookie 并不安全HTTP 协议不仅是无状态的，而且是不安全的。使用 HTTP 协议的数据不经过任何加密就直接在网络上传播， 有被截获的可能。使用 HTTP 协议传输很机密的内容是一种隐患。
  Session
  除了使用 Cookie，Web 应用程序中还经常使用 Session 来记录客户端状态。Session 是服务器端使用的
  一种记录客户端状态的机制，使用上比 Cookie 简单一些，相应的也增加了服务器的存储压力。

Session 是另一种记录客户状态的机制，不同的是 Cookie 保存在客户端浏览器中，而 Session 保存在服务器 上。
客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。

175515@2x.png

• 当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已 包含了一个 session 标识(称为 SessionId)
• 如果已包含则说明以前已经为此客户端创建过session，服务器就按照SessionId把这个session检索 出来，使用(检索不到，会新建一个)
• 如果客户端请求不包含SessionId，则为此客户端创建一个session并且生成一个与此session 相关联的 SessionId，SessionId 的值应该是一个既不会重复，又不容易被找到规律以仿造的字符 串，这个 SessionId 将被在本次响应中返回给客户端保存。
• 保存这个SessionId的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这 个标识发送给服务器。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍 然能够把 SessionId 传递回服务器。
  Cookie 和 Session 的区别:

1、cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
2、cookie 相比 session 不是很安全，别人可以分析存放在本地的 cookie 并进行 cookie 欺骗,考虑到安全 应当使用 session。
3、session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务 器性能方面，应当使用 cookie。
4、单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 cookie。而 session 存储在服务端，可以无限量存储
5、所以:将登录信息等重要信息存放为 session;其他信息如果需要保留，可以放在 cookie 中

IP 协议
IP协议是 TCP/IP 核心协议。
1、IP 协议的数据报格式(IPv4)

• 版本号：规定了数据报的 IP 协议版本(IPv4 还是 IPv6)。不同的 IP 版本使用不同的数据报格式 ， 上图是 IPv4 的数据报格式
• 首部长度：大多数 IP 数据报不包含选项，所以一般 IP 数据报具有 20 字节的首部。
• 服务类型：使不同类型的 IP 数据报能相互区别开来。
• 数据报长度：整个 IP 数据报的长度，利用首部长度和总长度就可以是算出 IP 数据报中数据内容的起始地址。该字段长度为 16 比特，所以 IP 数据报最长可达 2^16=65535 字节，而事实上，数据报很少有超过 1500 字节的

175527@2x.png

• 标识、标志、片偏移字段这三个字段与 IP 分片有关。此外，IPv6 不允许在路由器上对分组分片
• 生存时间TTL 用来确保数据报不会永远在网络中循环。设置该数据报可以经过的最多的路由器数。指定了 数据报的生存时间，经过一个路由器，它的值就减 1，当该字段为 0 时，数据报就被丢弃
• 协议该字段只有在一个 IP 数据报到达其目的地才有用。该字段值指示了 IP 数据报的数据部分应 交给哪个特定的传输层协议，比如，值为 6 表明要交给 TCP，而值为 17 则表明要交给 UDP
• 首部检验和与 UDP/TCP 的检验和不同，这个字段只检验数据报的首部，不包括数据部分。
• 选项字段：是一个可变长字段，选项字段一直以 4 字节作为界限。这样就可以保证首部始终是 4 字节的 整数倍。很少被用到
• 记录源IP地址和目的IP地址

IP 数据报分片

一个链路层帧能承载的最大数据量叫做最大传送单元(Maximun Transmission Unit,MTU),即链路层的 MTU 限制着 IP 数据报的长度。 问题是在不同的链路上，可能使用不同的链路层协议，且每种协议可能具有不同的 MTU。 假定在某条链路上收到一个 IP 数据报，通过检查转发表确定出链路，且出链路的 MTU 比该 IP 数据报的长 度要小，如何将这个过大的 IP 数据报压缩进链路层帧的有效载荷字段呢?
解决方案就是分片:将 IP 数据报中的数据分片为两个或更多个较小的 IP 数据报，用单独的链路层帧封装这 些较小的 IP 数据报，然后向出链路上发送这些帧，每个这些较小的数据都称为片(fragment)，片在到达目的地传输层前需要重新组装。

实际上，TCP 和 UDP 都希望从网络层上收到完整的未分片的报文。IPv4 的数据报重组工作是在端系统中， 而不是在网络路由器中。 当一台目的主机从相同源收到一系列数据时，需要确定这些数据报中的某些是否是一些原来较大的数据报 中的片。而如果是片的话，需要进一步确定何时收到最后一片，并且如何将这些片拼接到一起以形成初始 的数据报。从而就用到了前边说到的 IPv4 数据报首部中的标识、标志、片偏移 字段。

• 1、当生成一个数据报时，发送主机在为该数据报设置源和目的地址的同时在贴上标识号,发 送主机通常将为它发送的每个数据报标识号+1
• 2、当某路由器需要对一个数据报分片时，形成的每个数据报(即片)具有初始数据报的源 地址、目的地址和标识号
• 3、当目的地从同一发送主机收到一系列数据报时，它能够检查数据报的标识号以确定哪些 数据报实际上是同一较大数据报的片
• 4、由于IP协议是不可靠服务，一个或者多个片可能永远到达不了目的地。为了让目的主机 绝对相信它已收到初始数据报的最后一个片，最后一个片的标志比特被设为 0，其余被设为 1
• 5、为了让目的主机确定是否丢失了一个片，并且能按照正确的顺序重新组装片，使用偏移 字段指定该片应放在初始 IP 数据报的哪个位置> 此外，如果有一个片或者多个片未能到达，则该不完整的数据报将会被丢弃且不会交给传输 层。但如果传输层正使用着 TCP，则 TCP 将通过让源以初始数据来重传数据。因为 IP 层没有 超时重传机制，所以会重传整个数据报，而不是某个片

IPv4 编址

1、IP 地址

• 一台主机通常只有一条链路连接到网络，当主机上的 IP 想发送一条数据报时，就在该链路上发送。主机与 物理链路之间的边界叫做接口(interface)。 而路由器的任务是从链路上接收数据报并从某些其他链路转发出去，路由器必须有两条或更多链路与其连 接，路由器与它的任意一条链路之间的边界也叫做接口。即一台路由器会有多个接口，每个接口有其链路。
  因为每台主机与路由器都能发送和接收 IP 数据报，IP 要求每台主机和路由器接口都有自己的 IP 地址。因此， 一个 IP 地址技术上是与一个接口相关联的，而不是与包括该接口的主机或路由器相关联的。

2、子网
每个 IP 地址(IPv4)长度为 32 比特(4 字节)，按点分十进制记法书写，即地址中的每个字节都用它的十 进制形式书写，各字节间以点.隔开，比如 193.32.122.30 在因特网上的每台主机和路由器上的每个接口，必须有一个全球唯一的 IP 地址(NAT 后的接口除外)。这 些地址不能自由选择，一个接口的 IP 地址的一部分需要由其连接的子网来决定。
如图，一台路由器有三个接口，连接 7 台主机。左侧的三台主机以及连接它们的路由器的接口，都有一个 形如 223.1.1.x 的 IP 地址。即在它们的 IP 地址中，最左侧的 24 比特是相同的。

175540@2x.png

175550@2x.png

互联左侧这三个主机接口与 1 个路由器接口的网络形成 1 个子网(subnet)(也被称为 IP 网络或直接称为 网络)。IP 编址为这个子网分配一个地址:223.1.1.0/24，其中的/24 记法，有时称为子网掩码(network mask)，指示了 32 比特中的最左侧 24 比特定义了子网地址。任何连接到该子网的主机都要求其地址具有 223.1.1.x 的形式。同样图中下侧和右侧也是子网，分别为 223.1.3.0/24 和 223.1.2.0/24

上图显示了 3 台通过点对点链路彼此互联的路由器，这里出现了 6 个子网。 一个具有多个以太网段和点对点链路的组织将具有多个子网，在给定子网上的所有设备都具有相同的子网 地址。虽然在理论上来说，不同子网可以有完全不同的子网地址。但上图可以看出，这 6 个子网在前 16 个比特是 一致的，都是 223.1

3、无类别域间路由选择(CIDR)

因特网的地址分配策略被称为无类别域间路由选择(CIDR)(也被称为无分类编址，以区分于分类编址)。对 于子网寻址，32 比特的 IP 地址被分为两部分，也是点分十进制数形式 a.b.c.d/x，其中 x 指示了地址的 第一部分中的比特数，又被称为该地址的前缀(prefix)。 一个组织通常被分配一块连续的地址，即具有相同前缀的地址。在该组织外的的路由器仅考虑前面的前缀 比特 x，这相当大地减少了在这些路由器中转发表的长度，形式为 a.b.c.d/x 单一表项足以将数据报转发 到该组织内的任何目的地。

175606@2x.png

175618@2x.png

如图，200.23.16.0/20 下有 8 个组织，分别是 200.23.16.0/23 到 200.23.30.0/23，每个组织有自己的子 网。而外界不需要知道这 8 个组织。这种使用单个网络前缀通告多个网络的能力通常称为地址聚合，也称 为路由聚合或路由摘要

4、分类编址

在 CIDR 被采用之前，IP 地址的网络部分被限制长度为 8、16、24 比特，也就是分类编址(classful addressing)。 具有 8、16、24 比特子网地址的子网被称为 A、B 和 C 类网络。一个 C 类(/24)子网既能容纳 2 的 8 次方 - 2 = 254 台主机(其中两个地址预留用于特殊用途)，这对于 很多组织来说都太小了。
而一个 B 类(/16)子网可支持多达 2 的 16 次方 - 2 = 65534台主机，又太大了。在分类编址方法下，一个有 2000 台主机的组织通常被分给一个 B 类(/16)地址，那么剩下的 6 万多个地 址就浪费掉了。这就会导致 B 类地址空间的迅速损耗以及所分配的地址空间的利用率低。
此外，255.255.255.255 是 IP 广播地址，当一台主机发出一个目的地址为该地址的数据报时，该报文会 交付给同一个网络中的所有主机。

5、获取主机地址

某组织一旦获得了一块地址，它就可为本组织内的主机与路由器逐一分配 IP 地址。系统管理员通常手工配 置路由器中的 IP 地址。主机地址也能手动配置，但更多使用的是动态主机配置协议(DHCP)。DHCP 允许 主机自动获取 IP 地址。网络管理员可以配置 DHCP，以使某给定主机每次与网络连接时能得到一个相同的 IP 地址，或者某主机将被分配一个临时的 IP 地址，该地址在每次与网络连接时也许是不同的。

6、网络地址转换
每个 IP 地址(IPv4)长度为 32 比特(4 字节)，因此总共有 2[图片上传失败...(image-524f6a-1565267828082)]
个可能的 IP 地址，约为 40 亿个。在互联网越来越普及的当下，个人计算机及智能手机等越来越多，这些 IP 地址显然无法满足人们的需求。为了解决 IP 地址不足的问题，于是就有了网络地址转换(Network Address Translation， NAT)，它的思想就 是给一个局域网络分配一个 IP 地址就够了，对于这个网络内的主机，则分配私有地址，这些私有地址对外 是不可见的，他们对外的通信都要借助那个唯一分配的 IP 地址。
如果从广域网到达 NAT 路由器的所有数据报都有相同的目的 IP 地址，那么该路由器如何知道是发送给哪个 内部主机的呢?其原理就是使用在 NAT 路由器上的一张 NAT 转换表，并在该表内包含了端口号及其 IP 地 址。

• 假设一台主机向广域网请求数据，NAT路由器收到该数据报，会为该数据报生成一个新的端 口号替换掉源端口号，并将源 IP 替换为其广域网一侧接口的 IP 地址。当生成一个新的源端 口号时，该端口号可以是任意一个当前未在 NAT 转换表中的源端口号(端口号字段是 16 比 特，意味着 NAT 协议可以支持超过 60000 个并行使用路由器广域网一侧 IP 地址的连接)， 路由器中的 NAT 也在其 NAT 转换表中增加一表项。
• 该NAT路由器收到广域网返回的数据时，路由器使用目的IP地址与目的端口号从NAT转换 表中检索出该主机使用的 IP 地址和目的端口号，改写该数据报的目的 IP 地址和目的端口号， 并向该主机转发该数据报 NAT 虽然在近几年得到了很广泛的应用，但也被很多人反对。 主要是:
• 1、端口号是用来进程编址的，而不是主机编址的(NAT协议类似NAT路由器将该家庭网络 的主机都当做进程处理，并通过 NAT 转换表为其分配端口号)
• 2、路由器通常仅应当处理高达第三层的分组
• 3、违背端到端原则，即主机彼此之间应当相互直接对话，结点不应当介入修改IP地址与端 口号。
• 4、应当用IPv6来解决IP地址短缺问题 但不管反对与否，NAT 终究已成为当今因特网的一个重要组件
  IPv6 数据报格式

1、IPv6 数据报格式

• 版本(4比特)该字段用于标识 IP 版本号，IPv6 将该字段值设为 6。而如果将该字段设为 4 并不能创建一 个合法的 IPv4 数据报
• 流量类型(8比特)类似于 IPv4 数据报中的服务类型(TOS)
• 流标签(20比特)流标签字段是 IPv6 数据报中新增的一个字段，用来标识一条数据报的流类型，以便在网络 层区分不同的报文。
• 有效载荷长度(16比特)IPv6 数据报中在 40 定长字节数据报首部后的字节数量，即除了 IPv6 的数据报首部以外的其他部分的总长 度
• 下一个首部(8比特)当 IPv6 没有扩展报头时，该字段的作用和 IPv4 的协议字段一样。当含有扩展报头时，该字 段的值即为第一个扩展报头的类型
• 跳限制(8比特)与 IPv4 报文中的 TTL 字段类似，转发数据报的每台路由器将对该字段的内容减 1.如果跳限 制计数到达 0，则该数据报将被丢弃
• 源地址和目的地址(各128比特) 记录源 IP 地址，目的 IP 地址
• 数据

175629@2x.png

• 下一个首部(8比特)当 IPv6 没有扩展报头时，该字段的作用和 IPv4 的协议字段一样。当含有扩展报头时，该字 段的值即为第一个扩展报头的类型
• 跳限制(8比特)与 IPv4 报文中的 TTL 字段类似，转发数据报的每台路由器将对该字段的内容减 1.如果跳限 制计数到达 0，则该数据报将被丢弃
• 源地址和目的地址(各128比特) 记录源 IP 地址，目的 IP 地址
• 数据可以看出，在 IPv4 数据报中出现的几个字段在 IPv6 数据报中已不复存在:
• 分片/重新组装IPv6 不允许在中间路由器上进行分片和重新组装。这种操作只能在源与目的地上执行。如果 路由器收到的 IPv6 数据报因太大不能转发出链路上的话，路由器会丢掉该数据报，并回一 个“分组太大”的 ICMP 差错报文
• 首部检验和 因为运输层和数据链路层协议执行了检验操作，该项功能在网络层就没有必要了，从而更快 速处理 IP 分组
• 选项选项字段不再是标准 IP 首部的一部分了。但并没有消失，而是可能出现在 IPv6 首部中由“下 一个首部”指出的位置上。即就像 TCP 或 UDP 协议首部能够是 IP 分组中的“下一个首部”， 选项字段也能是“下一个首部”

IPv6 相对 IPv4 最重要的变化如下:

• 扩大的地址容量IPv6 将 IP 地址长度由 32 比特增加到 128 比特，这使得理论可存在的 IP 地址增加到约340万亿亿亿亿个，这是一个非常大的数字，确保全世界再也不会用尽IP地址，甚至可以为地球上每一粒沙子都分配一个唯一的 IP 地址除了单播和多播地址外，IPv6 没有广播这一说法，而是引入了一种称为任播地址的新型地址， 这种地址可以使数据报交付给一组主机中的任意一个
• 简化高效的40字节首部除去共 32 字节的源地址和目标地址外，首部其余字段只占了 8 字节
• 流标签与优先级 给属于特殊流的分组打上标签，这些特殊流是发送方要求进行特殊处理的流，如一种非默认 服务质量或需要实时服务的流

2、IPv6 书写和表达方式
表述和书写时，把长度为 128 比特的 IPv6 地址分成 8 个 16 位的二进制段、每一个 16 位的二进制段用 4 位
的 16 进制数表示，段间用“:”(冒号)隔开(其书写方法和 IPv4 的十进制数加“.”不同)。
例如: 1000:0000:0000:0000:000A:000B:000C:000D 就是每一个 16 位的二进制数的段用 4 位 16 进制数的段来表示、段间用“:”(冒号)隔开的一个 IPv6 地址; 其中: 各个 4 位 16 进制数的段中的高位 0 允许省略; 因此，上面的 IPv6 地址也可以缩写成:1000:0:0:0:A:B:C:D。

为了更进一步简化，IPv6 的地址规范中还规定，可以在一个 IPv6 地址中最多使用一次双冒号(::)来取代 IPv6 地址中紧密相连的多个全 0 的 16 进制数的段(因为如果允许在一个 IPv6 地址中使用一次以上的双冒 号时将无法判断 IPv6 地址的长度，所以 IPv6 的地址规范中才规定:在一个 IPv6 地址中最多只能使用一次 双冒号)，这样上面的 IPv6 地址还可以缩写成:1000::A:B:C:D。

双冒号使用的地点可以在 IPv6 地址的前面、后面或者是中间;例如:对于 1000:0:0:0:A:B:0:0 这样的 一个 IPv6 地址，可以写成 1000::A:B:0:0，也可以写成 1000:0:0:0:A:B::;但是不能写成 1000::A:B::。
带有端口号的 IPV6 地址字符串形式，地址部分应当用“[]”括起来，在后面跟着‘:’带上端口号，如 [A01F::0]:8000

从 IPv4 到 IPv6 的迁移

基于 IPv4 的公共因特网如何迁移到 IPv6 呢?这是个非常现实的问题虽然 IPv6 使能系统可做成向后兼容，即能接收、发送和路由 IPv4 数据报，但已部署的 IPv4 使能系统却不能处理 IPv6 数据报

1、双协议栈

引入 IPv6 使能结点的最直接方式是双栈方法，即使用该方法的 IPv6 结点还有完整的 IPv4 实现，即 IPv6/IPv4 结点，具有接收和发送 IPv4 和 IPv6 两种数据报的能力。当与 IPv4 结点互操作时，IPv6/IPv4 结点可使用 IPv4 数据报;当与 IPv6 结点互操作时，IPv6/IPv4 结点又可使用 IPv6 数据报。

IPv6/IPv4 结点必须有 IPv6 与 IPv4 两种地址。此外，它们还必须能确定另一个结点是否是 IPv6 使能的或 仅 IPv4 使能的。

可以使用 DNS 来解决，若要解析的结点名字是 IPv6 使能的，则 DNS 会返回一个 IPv6 地址，否则返回一个 IPv4 地址。如果发出 DNS 请求的结点是仅 IPv4 使能的，则只返回一个 IPv4 地址。
两个 IPv6 使能的结点不应相互发送 IPv4 数据报，而如果发送方或接收方任意一个仅为 IPv4 使能的,则必须 使用 IPv4 数据报。
这样就会有下面这种情况:

175640@2x.png

如图，假如结点 A、B、E、F 都是 IPv6 使能的结点，而结点 C 和 D 是仅 IPv4 使能的结点，那么当按 A->B->C->D->E->F 顺序发送数据报时,AB 之间会发 IPv6 数据报，BC 会发 IPV4 数据报， 由于 IPv6 数据报 特定的字段在 IPv4 数据报中无对应的部分，这些字段将会丢失。因此，即使 E 和 F 之间能发 IPv6 数据报， 从 D 到达 E 的 IPv4 数据报并未含有从 A 发出的初始 IPv6 数据报中的所有字段。

2、隧道

建隧道是另一种双栈方法，该方法能解决上述问题。假定两个 IPv6 结点要使用 IPv6 数据报进行交互，但是它们是经由中间 IPv4 路由器互联的。将两台 IPv6 路由器中间的 IPv4 路由器的集合成为一个隧道，如 B->C->D->E。

175650@2x.png

如图，借助于隧道，在隧道发送端的 IPv6 结点可将整个 IPv6 数据报放到一个 IPv4 数据报的数据字段中。 于是，该 IPv4 数据报的地址设为指向隧道接收端的 IPv6 结点，再发送给隧道中的第一个结点。而隧道中 的 IPv4 路由器在它们之间为该数据报提供路由，就像对待其他 IPv4 数据报一样，完全不知道该数据报自 身就含有一个完整的 IPv6 数据报。而隧道接收端的 IPv6 结点最终收到该 IPv4 数据报，并确定该 IPv4 数 据报中含有一个 IPv6 数据报，于是提取出该 IPv6 数据报，然后再为该 IPv6 数据报提供路由

3、NAT-PT

除了双栈和隧道方案外，还有一种 NAT-PT(Network Address Translator - Protocol Translator)附带协议转换器的网络地址转换器方案

全双工服务 ：数据传输有提交有返回，双向的服务

TCP建立连接的三次握手

1. 客户端发送SYN包到服务端
2. 服务端返回SYN/ACK包给客户端
3. 客户端发送ACK包给服务端，至此客户端和服务端达成链接，双方各有一个SYN/ACK包

175700@2x.png

断开链接的四次挥别

注意：四次挥别可以由客户端发起也可以由服务端发起

175710@2x.png

• 为什么是三次握手四次挥别，次数不一样 ？？？？？

为了保证数据完整性断开时ACK包 和 FIN包需要分开发送 ；

长连接和短连接

• 长连接用于一对一建立连接
• 短连接用于一对多建立连接

开发中常用到的是应用层协议

HTTP协议
HTTP 协议: 超文本传输协议 ，是一种详细规定了浏览器和万维网(WWW = World Wide Web)服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议，HTTP 是基于 TCP 的应用层协议；HTTP协议诞生于1990年，1.1版本之前是不支持长连接的，从1.1版本开始才支持长连接 ！目前最新版本是2.0

网络请求中很重要的两个报文：请求报文、响应报文

请求报文包含：请求行、首部行、空行、实体主体

响应报文包含：状态行、首部行、空行、实体主体

一些常见的状态码和对应的短语:

• 200 OK: 请求成功，信息在返回的响应报文中

• 301 Moved Permanently: 请求的对象已经被永久转移了，新的 URL 定义在响应报文中的 Location:首
  部行中。客户软件将自动获取新的 URL

• 400 Bad Request: 一个通用差错代码，指示该请求不能被服务器理解

• 404 Not Found:被请求的文件不在服务器上

• 505 HTTP Version Not Supported:服务器不支持请求报文使用的 HTTP 协议版本

• 4 开头的状态码通常是客户端的问题，5 开头的则通常是服务端的问题

HTTP 的请求方式

GET、POST、PUT、DELETE、HEAD、OPTIONS

1. GET 和 POST 方式的区别 从语法角度来看，最直观的区别就是

• GET 的请求参数一般以?分割拼接到 URL 后面，POST 请求参数在 Body 里面

• GET 参数长度限制为 2048 个字符，POST 一般是没限制的

• GET 请求由于参数裸露在 URL 中， 是不安全的，POST 请求则是相对安全
  之所以说是相对安全，是因为，如果 POST 虽然参数非明文，但如果被抓包，GET 和 POST 一样都是不安全的。(HTTPS 该用还是得用)

• 而从语义的角度来看:

• GET: 获取资源是 安全的，幂等的(只读的，纯粹的)， 可缓存的

• POST: 获取资源是 非安全的，非幂等的，不可缓存的
  这里的安全是指不应引起Server端的任何状态变化

• GET 的语义就是获取数据，是不会引起服务器的状态变化的，即是安全的。(HEAD，OPTIONS 也是安 全的)

• POST 语义则是提交数据，是可能会引起服务器状态变化的，即是不安全的

• 幂等: 同一个请求方法执行多次和执行一次的效果完全相同

• 这里用幂等形容 GET 还不够，因为 GET 不止是执行多次和执行一次的效果完全相同，而且是执行一次 和执行零次的效果也是完全相同的。

• 以上特性，并非并列，正是因为 GET 是幂等的只读的，即 GET 请求除了返回数据不会有其他副作用，所以 GET 才是安全的，从而可以直接由 CDN 缓存，大大减轻服务器的负担，也就是可缓存的。
  而 POST 是非幂等的，即除了返回数据还会有其他副作用，所以 POST 是不安全的，必须交由 web 服务器处 理，即是 不可缓存的

• GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于HTTP的规定和服务器的限制，导致他们 在应用过程中体现出一些不同。
  在响应时，GET 产生一个 TCP 数据包 ; POST 产生两个 TCP 数据包；
  对于 GET 方式的请求，浏览器会把 Header 和实体主体一并发送出去，服务器响应 200(返回数据);
  而对于 POST，浏览器先发送 Header，服务器响应 100 Continue，浏览器再发送实体主体，服务器响应 200 OK (返回数据)。

GET 相对 POST 的优势是什么?

1、最大的优势就是方便。GET 的 URL 可以直接手输，从而 GET 请求中的 URL 可以被存在书签里，或者历 史记录里

2、可以被缓存，大大减轻服务器的负担，所以大多数情况下，还是用 GET 比较好。

HTTP 的特点 ：无状态、无连接

1、HTTP 的无状态

即协议对于事务处理没有记忆能力

每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求时无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况 ；也就是说服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器

标准的 HTTP 协议指的是不包括 cookies，session，application 的 HTTP 协议 ；而在实际移动端开发中是需要用到cookies，session，application的，比如熟知的token，客户端需要一个证明身份的标识来验证身份请求数据

HTTP 的持久连接、Cookie/Session

175720@2x.png

非持久连接: 每个连接处理一个请求-响应事务。
持久连接: 每个连接可以处理多个请求-响应事务。
持久连接情况下，服务器发出响应后让 TCP 连接继续打开着。同一对客户/服务器之间的后续请求和响应可 以通过这个连接发送。
HTTP/1.0 使用非持久连接。HTTP/1.1 默认使用持久连接<keep-alive>。

非持久连接的每个连接，TCP 得在客户端和服务端分配 TCP 缓冲区，并维持 TCP 变量，会严重增加服务器 负担。而且每个对象都有 2 个 RTT(Round Trip Time，也就是一个数据包从发出去到回来的时间)的延迟，由 于 TCP 的拥塞控制方案,每个对象都遭受 TCP 缓启动，因为每个 TCP 连接都起始于缓启动阶段

HTTP 持久连接怎么判断一个请求是否结束的?

• Content-length:根据所接收字节数是否达到Content-length值
• chunked(分块传输):Transfer-Encoding。当选择分块传输时，响应头中可以不包含 Content-Length，服务器会先回复一个不带数据的报文(只有响应行和响应头和\r\n)，然后开始 传输若干个数据块。当传输完若干个数据块后，需要再传输一个空的数据块，当客户端收到空的数据 块时，则客户端知道数据接收完毕。

HTTP和HTTPS

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要收费
• HTTP是明文传输，HTTPS则是具有安全性的SSL加密传输
• HTTP和HTTPS使用的端口号也不一样，前者是80，后者是443
• HTTP可以进行加密传输、身份认证，比HTTP安全

150432@2x.png

• HTTPS 协议 = HTTP 协议 + SSL/TLS 协议

网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布第一版TLS标准文件。随后又公布RFC 5246 （2008年8月）与RFC 6176（2011年3月）。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议。主要的网站，如Google、Facebook等也以这个协议来创建安全连线，发送数据。目前已成为互联网上保密通信的工业标准。

SSL 的全称是 Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。推出于1994年

SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥（Session key）。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

TLS 的全称是: Transport Layer Security，即安全传输层协议；推出于1999年，TLS的前身是SSL****(安全套接层协议)，用于在两个通信应用程序之间提供保密性和数据完整性。

该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。

TLS协议采用主从式架构模型，用于在两个应用程序间透过网络创建起安全的连线，防止在交换数据时受到窃听及篡改。

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS协议是可选的，必须配置客户端和服务器才能使用。

总结：HTTPS 是安全的 HTTP

HTTPS 的连接建立流程

• HTTPS 为了兼顾安全与效率，同时使用了非对称加密和对称加密。在传输的过程中会涉及到三个密钥
• 服务器端的公钥和私钥，用来进行非对称加密
• 客户端生成的随机密钥，用来进行对称加密

HTTPS连接的8个步骤

1、客户端访问 HTTPS 连接
客户端会把安全协议版本号、客户端支持的加密算法列表、随机数 C 发给服务端。
2、服务端发送证书给客户端
服务端接收密钥算法配件后，会和自己支持的加密算法列表进行比对，如果不符合，则断开连接。
否则，服务端会在该算法列表中，选择一种对称算法(如 AES)、一种公钥算法(如具有特定秘钥长度的 RSA)和 一种 MAC算法发给客户端。
服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露; 公钥可以发送给任何人,在发送加密算法的同时还会把数字证书和随机数 S 发送给客户端
3、客户端验证 server 证书
会对 server 公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么 HTTPS 传输就无法继续。
4、客户端组装会话秘钥
如果公钥合格，那么客户端会用服务器公钥来生成一个前主秘钥(Pre-Master Secret，PMS)，并通过该前主秘钥和随机数 C、S 来组装成会话秘钥
5、客户端将前主秘钥加密发送给服务端
是通过服务端的公钥来对前主秘钥进行非对称加密，发送给服务端
6、服务端通过私钥解密得到前主秘钥
服务端接收到加密信息后，用私钥解密得到前主秘钥。
7、服务端组装会话秘钥
服务端通过前主秘钥和随机数 C、S 来组装会话秘钥。 至此，服务端和客户端都已经知道了用于此次会话的主秘钥。
8、数据传输
客户端收到服务器发送来的密文，用客户端密钥(会话秘钥)对其进行对称解密，得到服务器发送的数据。
同理，服务端收到客户端发送来的密文，用服务端密钥(会话秘钥)对其进行对称解密，得到客户端发送的数据。

总结:
会话秘钥 = random S + random C + 前主秘钥
1、HTTPS 连接建立过程使用非对称加密，而非对称加密是很耗时的一种加密方式
2、后续通信过程使用对称加密，减少耗时所带来的性能损耗
3、其中，对称加密加密的是实际的数据，非对称加密加密的是对称加密所需要的客户端的前主密钥

对称加密和非对称加密

1、对称加密

用同一套密钥来进行加密解密，对称加密通常有 DES, IDEA, 3DES 加密算法。

2、非对称加密

用公钥和私钥来加解密的算法，公钥(Public Key)与私钥(Private Key)是通过一种算法得到的一个密钥对(即一个公钥和一个私钥)， 公钥是密钥对中公开的部分，私钥则是非公开的部分,私钥通常是保存在本地。

1. 用公钥进行加密，就要用私钥进行解密; 反之，用私钥加密，就要用公钥进行解密(数字签名)。
2. 由于私钥是保存在本地的，所以非对称加密相对与对称加密是安全的。
3. 但非对称加密比对称加密耗时(100 倍以上),所以通常要结合对称加密来使用。

常见的非对称加密算法有: RSA、ECC(移动设备用)、Diffie-Hellman、El Gamal、DSA(数字签名用) ；而为了确保客户端能够确认公钥就是想要访问的网站的公钥，引入了数字证书的概念，由于证书存在一级 一级的签发过程，所以就出现了证书链，在证书链中的顶端的就是根 CA。
在HTTPS请求中，非对称加密应用在连接建立阶段，对称加密应用在数据传输阶段；

为什么会用到两个加密算法 ？？？？？？
首先加密是为了保证数据传输的安全性，防止被窃取捕获后攻击或篡改，非对称加密通过公私钥进行加密解密，安全性高但同时需要大量计算会比较耗时，对称加密也可以保证安全性，只是比非对称加密略低而已；网络请求时效性很重要，所以在验证阶段使用非对称加密确保链接的安全，在数据传输阶段用对称加密对数据加密；两者结合使用来既保证请求速度又保证了安全 ！这样的方案即合理有高效 ！！！

175747@2x.png

问题：即时通讯类应用，比如微信、QQ聊天使用的是长连接还是短连接 ？

客户端和服务器之间建立的是短连接，客户端和客户端之间建立的是长连接；使用protobuf数据格式传输；Protobuf一般多用于IM通讯

交互过程：A用户和B用户聊天

1. A请求聊天服务器想给B聊天
2. 服务器收到A请求后把消息甩给B，告诉他A想给你聊天
3. A和B建立长连接，开始聊天 ；聊天内容会定期以UDP形式上传到服务器保存

HTTP连接、TCP连接、socket连接有什么区别 ? HTTP支持长连接，那为什么还要使用socket来实现长连接呢 ？

HTTP 是应用层的协议，更靠近用户端；
TCP 是传输层的协议；
Socket 是从传输层上抽象出来的一个抽象层，本质是接口。

TCP连接与HTTP连接的区别
HTTP是对TCP/IP的应用层封装，TCP是属于传输层网络协议

TCP连接与socket连接的区别
socket层只是在TCP/UDP传输层上的抽象接口层，因次一个socket连接可以基于TCP也可以基于UDP。UDP协议是不需要建立连接过程的，不管对方收不收到消息我都发，不可靠的传输（游戏）所以“socket也是基于TCP”

HTTP连接与socket连接区别

HTTP是短连接，socket(基于TCP的)是长连接，虽然HTTP1.1版本后支持了长连接，但是不能够保证连接不会断开，而socket一旦建立连接，除非一端主动断开否则会一直保持连接状态；
HTTP长连接服务器端是无法主动发消息给客户端的，只能被动等客户端发消息才能响应；socket没有限制双方可以自由互发消息

理论上客户端和服务器端一旦建立起连接将不会主动断掉；但是由于各种环境因素可能会是连接断开，比如说：服务器端或客户端主机down了，网络故障，或者两者之间长时间没有数据传输，网络防火墙可能会断开该连接以释放网络资源。所以当一个socket连接中没有数据的传输，那么为了维持连接需要发送心跳消息~~具体心跳消息格式是开发者自己定义的.

HTTP支持UDP吗 ？

HTTP不支持UDP, HTTP是基于TCP/IP协议簇的应用层封装，是超文本传输协议，需要建立连接才可以通信；UDP不需要建立连接

DNS属于OSI模型的那一层，为什么?

NDS即域名系统，其作用是将字符串域名解析成相对于的服务器IP地址，免除人们记忆IP地址的单调和苦恼，属于为用户排忧解难之举，因此划归为应用层。

Socket

套接字（socket）是一个抽象层，应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。套接字允许应用程序将I/O插入到网络中，并与网络中的其他应用程序进行通信。网络套接字是IP地址与端口的组合。

传输层实现端到端的通信，因此，每一个传输层连接有两个端点。那么，传输层连接的端点是什么呢？不是主机，不是主机的IP地址，不是应用进程，也不是传输层的协议端口。传输层连接的端点叫做套接字（socket）。根据RFC793的定义：端口号拼接到IP地址就构成了套接字。所谓套接字，实际上是一个通信端点，每个套接字都有一个套接字序号，包括主机的IP地址与一个16位的主机端口号，即形如（主机IP地址：端口号）。例如，如果IP地址是210.37.145.1，而端口号是23，那么得到套接字就是（210.37.145.1：23）。

总之，套接字Socket=（IP地址+端口号），套接字的表示方法是十进制的IP地址后面写上端口号，中间用冒号或逗号隔开。每一个传输层连接唯一地被通信两端的两个端点（即两个套接字）所确定。

套接字可以看成是两个网络应用程序进行通信时，各自通信连接中的一个端点。通信时，其中的一个网络应用程序将要传输的一段信息写入它所在主机的Socket中，该Socket通过网络接口卡的传输介质将这段信息发送给另一台主机的Socket中，使这段信息能传送到其他程序中。因此，两个应用程序之间的数据传输要通过套接字来完成。

在网络应用程序设计时，由于TCP/IP的核心内容被封装在操作系统中，如果应用程序要使用TCP/IP，可以通过系统提供的TCP/IP的编程接口(Socket接口)来实现。

在Windows环境下，网络应用程序编程接口称作Windows Socket。为了支持用户开发面向应用的通信程序，大部分系统都提供了一组基于TCP或者UDP的应用程序编程接口（API），该接口通常以一组函数的形式出现，也称为套接字（Socket）。

分类

为了满足不同的通信程序对通信质量和性能的要求，一般的网络系统提供了三种不同类型的套接字，以供用户在设计网络应用程序时根据不同的要求来选择。这三种套接为流式套接字（SOCK-STREAM）、数据报套接字（SOCK-DGRAM）和原始套接字（SOCK-RAW）。

（1）流式套接字。它提供了一种可靠的、面向连接的双向数据传输服务，实现了数据无差错、无重复的发送。流式套接字内设流量控制，被传输的数据看作是无记录边界的字节流。在TCP/IP协议簇中，使用TCP协议来实现字节流的传输，当用户想要发送大批量的数据或者对数据传输有较高的要求时，可以使用流式套接字。

（2）数据报套接字。它提供了一种无连接、不可靠的双向数据传输服务。数据包以独立的形式被发送，并且保留了记录边界，不提供可靠性保证。数据在传输过程中可能会丢失或重复，并且不能保证在接收端按发送顺序接收数据。在TCP/IP协议簇中，使用UDP协议来实现数据报套接字。在出现差错的可能性较小或允许部分传输出错的应用场合，可以使用数据报套接字进行数据传输，这样通信的效率较高。

（3）原始套接字。该套接字允许对较低层协议（如IP或ICMP）进行直接访问，常用于网络协议分析，检验新的网络协议实现，也可用于测试新配置或安装的网络设备。 [1]

socket是网络通信的基础，位于传输层，是非常底层的一套API，它无限接近于硬件并且是跨平台的哦 ！！

socket 即套接字，网络连接需要一对套接字建立端和端连接；可以认为是传输层到应用层连接的桥梁；socket协议本身并不是协议只是一套用于调用TCP/IP的C语言API。socket就是由IP地址 +端口号组成；

简单总结：

socket就是套接字，计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

下图中的write()在iOS开发中多用 send() 就是消息发送

175758@2x.png

通信分为五步

1. 创建socket
2. 连接到服务器
3. 发送数据到服务器
4. 接收服务器返回数据
5. 断开链接

HTTP端口号是80，但是在开发中发现输出的sin_port是20480这样的值 ，为什么 ？
因为在网络传输过程中高低位和开发中是不一样的，会把高低位进行互换这样我们看到的就是20480

ip地址设定127.0.0.1，在开发中还是127.0.0.1吗 ？
不是，在网络中会变成整形数，比如：16777343

175810@2x.png

下面connect()函数中为什么需要传递结构体地址和长度 ？

175819@2x.png

因为结构体地址只能够表示从哪里开始是属于这个结构体，但不能表示到哪里结束；传递结构体大小就可以确定结构体内存到哪里结束 ！

1. 有一个问题编写代码时编写到下图红框中的connResult时编译器没有提示为什么 ？

   
   
   175828@2x.png

哈哈哈😁，因为Log中输入了中文呀 ！有中文就不给提示咯。。。。 少年

socket开发用到的命令

• $ nc -lk 12345 :始终监听本地计算机12345端口的数据
• Netcat
  是终端下用于调试和检查网络的工具包，可用于创建TCP/IP连接

socket在开发中的应用 ？

约定协议

完整的数据包 = 服务号 + 数据包长度 + 数据
数据包头 ＝ Id(4B) + length(4B) 共占用8字节
数据包 = length（假设占100个字节）

WX20210117-175847@2x.png

由于需求都会有所不同，可根据自己业务需求来选择使用TCP或者UDP。在入门篇先介绍CocoAsyncsocket中TCP的用法。
导入头文件#import <CocoaAsyncSocket/GCDAsyncSocket.h>

1.创建socket的实例对象(可根据业务创建多个,但建议只做一个即可)：

175855@2x.png

2.连接服务端：

175907@2x.png

• connectToHost的参数是传ip，port是传端口。
• withTimeout的参数为什么是-1，因为设置其他为时间会出现超时，必然会断线。

3.实现delegate的方法：

175920@2x.png

• sock即返回正在使用的socket，data即接收到返回的二进制数据（由客户端和服务端协商该用什么样的标识作为收发的数据包），tag即所在socket线程收到二进制数据的标签。
• 在这个方法里面进行解析数据，根据业务需求对数据进行切包、拼包，需要注意的是在这个方法里面要处理丢包的情况。

183326@2x.png

socket断线分3种情况，一种是是否自己主动切断（登出），一种是是否网络状态不好而断线（这种情况应该为用户进行断线重连），一种是服务端拒绝（最大原因是处于服务器负载量过大)。

4.发送数据到服务端：

183442@2x.png

• writeData传的数据当然只能是二进制，所以需要进行转换；withTimeout是给传的这个当前数据设置一个超时时间，若并发量大的时候就应该考虑该因素；tag是给当前发送的这个数据上标签。

• 由于收发数据包是不会自动释放缓存的二进制数据，这样会造成粘包和接收不到下一个包的问题，所以每次收发完数据包都需要进行一个释放数据包的动作，实现以下方法即可

  
  
  183548@2x.png

• withTimeout是随着收发的socket进行对应的超时时间设置，tag即对应数据包的标签。
  实现以上步骤即可完成一个初步的TCP连接并进行数据的收发。

HTTPS绝对安全吗 ？？？？

HTTPS在完全加密过程是一定安全的，但比如您本地的网络被篡改指向了一个不安全网站，然而这个网站可能也是一个假的HTTPS，这种情况下是不安全的。那么在HTTPS情况下，比如EV SSL证书，采取的地址栏直接提示企业名称，比如银行EV，他们可以确保是一定安全的。普通的DV SSL证书用于数据的加密协议传输，不足以识别真假网站的功能答，所以对于数据协议上的传输，防劫持等是没有问题的。

URL 是什么 ？
中文名称：统一资源定位系统
英文名称：uniform resource locator;URL
定　　义：因特网的万维网服务程序上用于指定信息位置的表示方法。
应用学科 ：通信科技（一级学科），服务与应用（二级学科）

URL由三部分组成：资源类型、存放资源的主机域名、资源文件名。
也可认为由4部分组成：协议、主机、端口、路径
URL的一般语法格式为：http://baidu.com
(带方括号[]的为可选项)：protocol :// hostname[:port] / path / [;parameters][?query]#fragment

格式说明

编辑

protocol（协议）

指定使用的传输协议，下表列出 protocol 属性的有效方案名称。 最常用的是HTTP协议，它也是WWW中应用最广的协议。

file 资源是本地计算机上的文件。格式file:///，注意后边应是三个斜杠。

ftp 通过 FTP访问资源。格式 FTP://

gopher 通过 Gopher 协议访问该资源。

http 通过 HTTP 访问该资源。 格式 HTTP://

https 通过安全的 HTTPS 访问该资源。 格式 HTTPS://

mailto 资源为电子邮件地址，通过 SMTP 访问。 格式 mailto:

MMS 通过 支持MMS（流媒体）协议的播放该资源。（代表软件：Windows Media Player）格式 MMS://

ed2k 通过 支持ed2k（专用下载链接）协议的P2P软件访问该资源。（代表软件：电驴） 格式 ed2k://

Flashget 通过 支持Flashget:（专用下载链接）协议的P2P软件访问该资源。（代表软件：快车） 格式 Flashget://

thunder 通过 支持thunder（专用下载链接）协议的P2P软件访问该资源。（代表软件：迅雷） 格式 thunder://

news 通过 NNTP 访问该资源。

hostname（主机名）

是指存放资源的服务器的域名系统(DNS) 主机名或 IP 地址。有时，在主机名前也可以包含连接到服务器所需的用户名和密码（格式：username:password@hostname）。

port（端口号）

整数，可选，省略时使用方案的默认端口，各种传输协议都有默认的端口号，如http的默认端口为80。如果输入时省略，则使用默认端口号。有时候出于安全或其他考虑，可以在服务器上对端口进行重定义，即采用非标准端口号，此时，URL中就不能省略端口号这一项。

path（路径）

由零或多个“/”符号隔开的字符串，一般用来表示主机上的一个目录或文件地址。

parameters（参数）

这是用于指定特殊参数的可选项。

query(查询)

可选，用于给动态网页（如使用CGI、ISAPI、PHP/JSP/ASP/ASP.NET等技术制作的网页）传递参数，可有多个参数，用“&”符号隔开，每个参数的名和值用“=”符号隔开。

fragment（信息片断）

字符串，用于指定网络资源中的片断。例如一个网页中有多个名词解释，可使用fragment直接定位到某一名词解释。

Get请求的参数有什么要求吗 ？
参数不能带特殊字符和问号

客户端发起一个网络请求都经历了什么？
请求和响应的详细经过

http图解.png