├── README.md ├── link ├── 0000.md ├── 0001.md ├── 0002.md ├── 0003.md ├── 0004.md ├── 0005.md ├── 0006.md ├── 0007.md ├── 0008.md ├── 0009.md ├── 000A.md ├── 000B.md ├── 000C.md ├── 000D.md ├── 000E.md ├── 000F.md ├── 0010.md ├── 0011.md ├── 0012.md ├── 0013.md ├── 0014.md ├── 0015.md ├── 0016.md ├── 0017.md ├── 0018.md ├── 0019.md └── 001A.md └── res ├── Compare.png ├── DNS1.png ├── DNS2.png ├── FTP1.gif ├── FTP2.png ├── FTP3.jpg ├── OSI.png ├── POP3.png ├── POP3transform.jpg ├── SOAP1.png ├── SOAP2.jpg ├── TCPClose.png ├── TCPCreate.png ├── TLS_SSL1.jpg ├── TLS_SSL2.png ├── TLS_SSL3.png ├── UDP Header.jpg ├── UDP Helper.jpg ├── UDP.png ├── XMPP1.gif ├── XMPP2-5.png ├── XMPP2.png ├── XMPP3.jpg ├── Yesky-1.png ├── Yesky-2.png ├── aloha.png ├── chrome-1.png ├── chrome-2.png ├── cmd.png ├── cmd2.png ├── compare.png ├── comparility.png ├── con.png ├── correct_code1.png ├── cti.png ├── datagram.png ├── dvr.png ├── envirnment.png ├── iPv4 Header.png ├── imap.png ├── ipheader.png ├── par.png ├── popvsimap.png ├── relationship.png ├── routing.png ├── smtp1.gif ├── smtp2.jpg ├── summary.png ├── telent1.gif ├── telent2.jpg ├── vc.png └── window.png /README.md: -------------------------------------------------------------------------------- 1 | # 计算机网络技术共享博客（每周三、周六更新） 2 | ## 目录 3 | ####Seahub分目录 4 | 1. [Article 0000 - IPv4](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0000.md) 5 | 2. [Article 0002 - REST API互联网软件架构](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0002.md) 6 | 3. [Article 0004 - 传输层之TCP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0004.md) 7 | 4. [Article 0006 - 传输层之UDP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0006.md) 8 | 5. [Article 0008 - 传输层之QUIC协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0008.md) 9 | 6. [Article 000A - 应用层之SMTP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000A.md) 10 | 7. [Article 000C - 应用层之POP3协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000C.md) 11 | 8. [Article 000E - 应用层之IMAP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000E.md) 12 | 9. [Article 0010 - 应用层之DNS](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0010.md) 13 | 10. [Article 0012 - 应用层之SOAP](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0012.md) 14 | 11. [Article 0014 - 应用层之FTP](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0014.md) 15 | 12. [Article 0016 - 应用层之Telent](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0016.md) 16 | 13. [Article 0018 - 应用层之XMPP](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0018.md) 17 | 14. [Article 001A - SSL/TLS PartI: Encryption](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/001A.md) 18 | 19 | ####Samray分目录 20 | 1. [Article 0001 - 计算机网络参考模型](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0001.md) 21 | 2. [Article 0003 - 物理层](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0003.md) 22 | 3. [Article 0005 - 浅谈数据链路层01](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0005.md) 23 | 4. [Article 0007 - 浅谈数据链路层02](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0007.md) 24 | 5. [Article 0009 - 今天不谈协议--谈谈实践之DNS服务器搭建](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0009.md) 25 | 6. [Article 000B - 浅谈数据链路层03--基本数据链路层协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000B.md) 26 | 7. [Article 000D - 浅谈数据链路层04--滑动窗口协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000D.md) 27 | 8. [Article 000F - 浅谈数据链路层05之介质访问控制子层](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000F.md) 28 | 9. [Article 0011 - 浅谈数据链路层06之多路访问协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0011.md) 29 | 10. [Article 0013 - 浅谈网络层01之认识网络层](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0013.md) 30 | 11. [Article 0015 - 浅谈网络层02之路由算法](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0015.md) 31 | 12. [Article 0017 - 浅谈网络层03之路由算法](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0017.md) 32 | 13. [Article 0019 - 浅谈网络层04之IPv4协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0019.md) 33 | 34 | ## 博客简述 35 | * 本博客用于整理计算机网络技术相关资料、笔记，欢迎各界人士参与编写(通过Pull Requst即可参与) 36 | * 本博客建立目的： 37 | * 整理现有较为混乱的计算机网络技术 38 | * 通过编写与核对，共享作者之间达到共同进步，相互讨论 39 | * 做一件有意义的事情 40 | 41 | ## 关于参与编写本共享博客 42 | ### 权利 43 | 1. 拥有邀请编写人的权利 44 | 2. 长期编写人的用户名将会被记录在本文档“共享作者”一列 45 | 46 | ### 义务 47 | 1. 每周必须至少编写一篇计算机网络技术相关的文章 48 | 2. 有义务检查其他编写者的文章正确性，一旦发现错误，需及时勘误并通知相关编写者 49 | 50 | #### 共享博文编写规则 51 | 0. 每篇文章必须是自己通过思考/总结/翻译独立创作，不能把“复制粘贴”作为一种编写途径 52 | 1. 每篇文章需在顶部标明阅读难度、在底部标明姓名及日期 53 | 2. 每篇文章均需以另一个Markdown文档的形式放在link文件夹下，资源文件放在res文件夹下，命名格式为0000 ~ FFFF依次按序命名 54 | 3. 每篇文章更新后需要同步更新本博客目录（要求使用超链接） 55 | 4. 每篇文章必须按照Markdown格式编写 56 | * Win Markdown推荐工具：Cmd Markdown 57 | * Mac Markdown推荐工具：Mou / Cmd Markdown 58 | * Linux Markdown推荐工具：Cmd Markdown 59 | * 全平台推荐工具： Sublime + 插件 / Cmd Markdown 60 | * Web Markdown推荐工具：简书、Cmd Markdown、github 61 | 5. 每篇文章完成编写后需要进行Pull Requst，且Commit信息不能为空 62 | 63 | ## 共享博客作者名单 64 | * Seahub(seahubc@gmail.com) 65 | * Samray(samrayleung@gmail.com) 66 | 67 | 68 | -------------------------------------------------------------------------------- /link/0000.md: -------------------------------------------------------------------------------- 1 | # IPv4简述 2 | * 阅读难度:低 3 | 4 | ## IPv4 - 定义 5 | > IPv4(Internet Protocol Version 4, 互联网通讯协议第四版)，是一种使用32位地址的，无连接，工作在网络层(OSI模型第三层)的协议。 6 | 7 | ## IPv4 - 报头 8 | ![IPv4 Header](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/iPv4%20Header.png?raw=true) 9 | 10 | ## IPv4 - 分类网络 - 简述 11 | ### 定义 12 | > 分类网络（Classful Addressing）或称“分级式定址”，是用于描述互联网的网络体系的一个术语。它将IPv4的IP地址分成五个类别。 13 | 14 | ### 分类体系 15 | * A类(1 - 126.x.x.x)(形式: "1 + 7 + 24")（单播） 16 | * 地址介于1 - 126之间 17 | * 地址组成: 固定一位"0" + 可变7位(网络号) + 可变24位(主机号) 18 | * B类(128 - 191.x.x.x)（形式: "2 + 14 + 16"）(单播) 19 | * 地址介于128 - 191之间 20 | * 地址组成: 固定两位"10" + 可变14位(网络号) + 可变16位（主机号） 21 | * C类(193 - 223.x.x.x)(形式: "3 + 21 + 8")(单播) 22 | * 地址介于192 - 223之间 23 | * 地址组成: 固定三位"110" + 可变21位(网络号) + 可变8位（主机号） 24 | * D类地址 (224 - 240.x.x.x)（形式:"4 + 28"）(组播) 25 | * 地址介于224 - 240之间 26 | * 地址组成:固定四位"1110" + 无特定作用的28位二进制数 27 | * E类地址(240 - 255.x.x.x)(形式:"4 + 28")（保留） 28 | * 地址介于240 - 255之间 29 | * 地址组成:固定四位"1111" + 无特定作用的28位二进制数 30 | 31 | 32 | ## IPv4 - 无类域间路由(CIDR) - 简述 33 | ### 定义 34 | > CIDR将路由集中起来，使一个IP地址代表主要骨干服务提供商(ISP)的几千个IP地址，ISP再将地址分配给客户，从而减轻Internet路由器的负担。 35 | 36 | ### CIDR主要工作原理 37 | * 子网划分：增加网络位，减少主机位 38 | * 子网汇聚:减少网络位，增加主机位 39 | * 方法：将VLSM形式表示的IP地址转换成二进制位，抽取相同的二进制位组成超网二进制地址 40 | * 例子：将192.168.0.0/24，192.168.1.0/23，192.168.2.0/22，192.168.3.0/24汇聚成一个超网地址 41 | 42 | step 1: 提取十进制位相同部分,简化计算过程 43 | 由于例子中子网地址均含"192.168",故超网前十六位地址亦为192.168.x.x 44 | step 2: 将剩余位化为二进制 45 | 192.168.0.0/24 = 192.168.0000 0000.0000 0000 46 | 192.168.1.0/23 = 192.168.0000 0001.0000 0000 47 | 192.168.2.5/22 = 192.168.0000 0010.0000 0101 48 | 192.168.3.0/24 = 192.168.0000 0011.0000 0000 49 | step 3: 提取相同部分，即为汇聚后的地址：192.168.0.0/22 50 | 51 | ## IPv4 - 特殊的保留地址表及对应用途 52 | | IPv4 地址 | 用途 | 53 | | :-------: | :----: | 54 | | 0.0.0.0 | 整个网络中所有主机：帮助路由器发送路由表中无法查询的包 | 55 | | 10.0.0.0 | A类保留地址：用于局域网地址通信 | 56 | | 100.64.0.0 | A类保留地址：用于局域网地址通信 | 57 | | 127.0.0.0 | 环回地址：用于主机向自身发送通讯 | 58 | | 169.254.0.0 | 私有地址：用于自动获取IP地址 | 59 | | 172.16.0.0 | B类保留地址：用于局域网地址通信 | 60 | | 192.0.0.0 | 广播地址：用于广播该网段内的信息 | 61 | | 192.0.2.0 | IANA保留网络测试地址：用于网络测试(TEST-NET-1) | 62 | | 192.88.99.0 | 6to4中继地址：用于IPv4与IPv6的过渡 | 63 | | 192.168.0.0 | C类保留地址：用于局域网地址通信 | 64 | | 198.18.0.0 | 网络基准测试地址：用于网络性能测试 | 65 | | 198.51.100.0 | IANA保留网络测试地址：用于网络测试(TEST-NET-2) | 66 | | 203.0.113.0 | IANA保留网络测试地址：用于网络测试(TEST-NET-3) | 67 | | 224.0.0.0 | 组播基准地址：用于一些特定的程序以及多媒体程序 | 68 | | 240.0.0.0 | E类保留地址 | 69 | | 255.255.255.255 | 限制广播地址：用于向本网段内的所有主机发送广播 | 70 | > [完整保留地址表](http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml) 71 | 72 | ## IPv4 - 缺陷提出与解决 73 | * 缺陷： 74 | * 地址缺陷:由于地址空间只有4,294,967,296个(2的32次方)，随着联网设备的不断增加，IPv4地址不够用于分配给每一个用户 75 | * 性能缺陷：由于部分设计过时，修改后可以提高潜在性能，如减少路由器路由表，解决“路由瓶颈问题” 76 | * 安全缺陷：IPv4设计只具备最少的安全性选项，应用的安全性责任被扔到了应用层(OSI模型第七层) 77 | * 解决方法：Ipv6的部署 78 | 79 | 80 | ## 子网掩码 81 | ### 定义 82 | > 子网掩码是一种用来指明一个IP地址的哪些位标识的是主机所在的子网，以及哪些位标识的是主机的位掩码 83 | 84 | ### 作用 85 | 1. 将某个IP地址划分成网络地址和主机地址两部分 86 | 2. 将一个大的IP网络划分为若干个子网络 87 | 3. 判断任意两个IP是否属于同一子网，说明该IP地址是在局域网上还是在远程网上 88 | 89 | ### 相关计算 90 | * 定义：IPv4地址中标识网络号的所有对应二进制位都用"1"，标识主机号的所有对应二进制位都用"0" 91 | * 因此，根据分类网络中A、B、C三类IPv4地址划分，缺省的子网掩码为 92 | * A类IPv4地址缺省掩码:255.0.0.0 93 | * B类IPv4地址缺省掩码:255.255.0.0 94 | * C类IPv4地址缺省掩码:255.255.255.0 95 | 96 | * 计算方法 97 | * 计算子网掩码 98 | 1. 转为二进制 99 | 2. 其中网络位和子网位 = 1，主机位 = 0 100 | 3. 转为点分十进制，得出子网掩码 101 | * 子网数 = 2的子网位次方 - 2 102 | * 主机数 = 2的主机位次方 - 2 103 | * 网络地址 = IP地址 "与" 子网掩码 = 网络位、子网位不变，主机位置零 104 | * 主机地址 = IP地址 “取反后再与" 子网掩码 105 | * 广播地址 = 网络位、子网位不变，主机位置一 = 整个网络段中最后一个IP地址 106 | 107 | ---- 108 | ## IPv4、IPv6转换方法 109 | 1. 隧道：在纯ipv4/ipv6环境下通过映射转换后访问 110 | * IPv6 over IPv4隧道技术(封包 - 拆包):使得分散的IPv6孤岛可以跨越IPv4网络相互通信 111 | * GRE隧道技术 112 | * 手工配置隧道技术 113 | * 利用IPv4兼容地址的自动隧道技术 114 | * 6over4技术 115 | * 6to4技术 116 | * ISATAP技术 117 | * Teredo技术 118 | * 6RD技术 119 | * IPv4 over IPv6隧道技术:解决具有IPv4的接入设备成为IPv6中的孤岛通信问题 120 | * DS-Lite隧道技术 121 | 2. 双协议栈：使得网络上的节点设备同时支持ipv4与ipv6的协议访问 122 | 3. 翻译模式：在IPv4与IPv6之间建立映射关系 123 | 124 | > 可通过www.SixXS.org 提供的Ipv通道访问Ipv6 站点的服务访问网站, 后缀 .sixxs.org 代表使用sixxs.org提供的IPv6网关，该网关将来自IPv6网络的http访问请求转换成IPv4的http请求，访问任何其他IPv4的 http都可以使用这个网关，在域名后面加上 ipv4.sixxs.org 即可。 125 | 126 | 127 | ## 补充阅读 128 | 1. [OSI模型](https://zh.wikipedia.org/wiki/OSI%E6%A8%A1%E5%9E%8B) 129 | 2. [多播/组播/群播](https://zh.wikipedia.org/wiki/%E5%A4%9A%E6%92%AD) 130 | 131 | ------ 132 | * 文章编写人: Seahub 133 | * 更新时间: 2016-3-30 134 | 135 | 136 | -------------------------------------------------------------------------------- /link/0001.md: -------------------------------------------------------------------------------- 1 | #计算机网络参考模型 2 | * 阅读难度:低 3 | 4 | 我先介绍两个很重要的网络体系结构:OSI(Open System Interconnection Reference Model)模型和TCP/IP模型。虽然OSI模型相关的协议没有被广泛使用，但是该模型还是有很重要的參考意义的，而TCP/IP模型刚好与之相反，它的模型很少被提及，但是它的协议就被广泛地使用。所以涅，我们还是值得好好讨论一下这两个模型 5 | 6 | ![参考图](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/OSI.png) 7 | 8 | ##OSI模型有7层，每层的基本原理如下 9 | 1. 每层的功能应该执行一个明确的功能 10 | 11 | 2. 层与层边界的选择应该使跨越接口的信息流最小 12 | 13 | 3. 层数应该足够多,保证不同的功能不会混杂在一层，同时层数不能太多，以免体系结构变得过于庞大 14 | 15 | 保证原理实现的一个重点是层与层之间的接口定义清晰，这样不仅可以减少层与层之间的信息量， 16 | 17 | 还可以使同层的协议替换更加容易，即同一层的当前协议或实现替换成另外一个完全不同的协议或者实现。类比过去，这就跟程序开发过程中要求尽量实现高内聚，松耦合的理念很相似。都为了系统健壮和方便维护的目的 18 | 19 | 下面我就简要地说一下OSI模型 20 | 21 | * 物理层（Physical Layer）：关注在一条信道上传输原始比特，负责管理电脑通信设备和网络媒体之间的互通，这是ISO模型的最低层了 22 | 23 | * 数据链路层（(Data Link Layer）：主要任务是将一个原始的传输设施转变成一条没有漏检错误的线路，负责网络寻址、错误侦测和改错。当网络层把数据交给链路层时，链路层就会将数据包封装成帧再发传输出去。一帧包括帧头，有效载荷，帧尾 24 | 25 | * 网络层(Network Layer)：主要要考虑的东西就是如何将数据包从源端路由发送到接收方，决定数据的路径选择和转寄，这个就跟路由的算法有关了，我以后会详细介绍，现在就先了解一下 26 | 27 | * 传输层(Transport Layer)：传输层就是接收来自上一层的数据，然后在数据包较大的时候，将数据分隔层较少的单元，然后把这些单元传输到网络层，确保到达另一端的传输层，并保证服务的质量。参考上面的图解 28 | 29 | * 会话层(Session Layer):会话层控制不同电脑之间的会话，具体而言呢，就是它建立，管理，结束本地和远程应用之间的连接。会话层通常提供各种服务，例如提到的会话管理，还有令牌管理(不允许源端和接收方同时进行某些关键操作，类比操作系统处理并发的令牌管理)，同步功能(就是提供断点，在系统崩溃的时候恢复到断点时的状态) 30 | 31 | * 表示层(Presentation Layer)：表示层在应用层之间建立关联,即使应用层之间使用不同的语法和语义，表示层也能通过映射来解决它们之间的差异 32 | 33 | * 应用层(Application Layer)：应用层呢，就是与用户的软件直接交互的了，很自然地就包括到了各种协议啦，例如我们见得非常多的超文本传输协议HTTP,还有文件传输协议FTP，电子邮件SMTP，远程登录的SSH 34 | 35 | ## TCP/IP参考模型 36 | 这个模型相信很多读者都有所耳闻，不过大家应该了解的都是TCP/IP协议，我最开始了解TCP/IP 也是因为它的协议，但是我现在要介绍的是被称为TCP/IP的参考模型，它最开始是源于美国的国防部的一个军用项目的。 37 | 38 | 严格来说TCP/IP只有三个层，不过一般被认为有4层，嗯，怎么回事呢？ 39 | 40 | * 链路层（link layer）：这是模型的最低层，描述了链路必须完成什么样的功能才能满足无连接网络层的要求。这个不是真正意思上的一个层，它只是数据包从一个设备的网络层传输到另外一个设备的网络层的方法，换而言之，它是主机和传输线路之间的一个接口 41 | 42 | * 网络互联层（internet layer ）:它大致对应于 OSI的网络层，主要任务是允许主机将数据包注入到任何网络，并且让这些数据包独立(可以经过不同的网络)到达接收方 43 | 44 | * 传输层(transport layer)：大致对应OSI的传输层,能够解决诸如端到端可靠性（“数据是否已经到达目的地？”）和保证数据按照正确的顺序到达这样的问题,另一方面，提供的这种端对端服务是可以独立与用户数据的结构的，并且能做到不依赖下层的的网络 45 | 46 | * 应用层(application layer)：它就是和OSI的应用层一样，负责和用户的交互,包含了所有的高层协议，例如上面提到的HTTP,FTP,SMTP。 47 | 48 | ## 说了这两个模型这么多的东西了，是时候来比较一下两个模型的了 49 | ![比较](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/Compare.png) 50 | 51 | 52 | 53 | 54 | 两个模型有很多的相似，例如都是以协议栈概念基础，并且协议栈的协议彼此独立，除此之外，协议的功能都大致相似 55 | 56 | 但是它们是两个不同的模型，就说明它们有很多的不同点了 57 | 58 | 例如OSI模型的核心是： 59 | 60 | 1. 1.服务 61 | 62 | 2. 2.接口 63 | 64 | 3. 3.协议 65 | 66 | 有些学者觉得OSI模型的最大贡献就是区分了这三个概念。服务定义说明了该层是干什么的，而不是上一层怎么访问下一层；接口定义了上面的进程怎么访问本层；用到什么协议就是本层自己内部的关系了，它喜欢用什么就用什么（假如它知道什么是喜欢）,只要它实现了它要提供的服务就行了 67 | 68 | 但是呢，TCP/IP模型是没有明确区分服务，接口，协议的。另外TCP/IP的协议和模型高度吻合，那么，一方面，它们两者结合得很好，另一方面，TCP/IP模型不适合其他的任何的协议栈 ，例如我们没办法用TCP/IP模型描述蓝牙。还有我们刚刚提到的，TCP/IP 只是3层的模型，链路层并不是真正意思的一层，只是一个接口，还有就是物理层和链路层也没有严格区分，但这两个是完全不同的层 69 | 70 | 最后来总结一下吧，OSI的模型设计得很好，但是具体的实现技术就有问题，力图让某些功能重复出现在每一层，造成低效，还有模型的一些糟糕实现，与之相反的是，TCP/IP的协议设计得很好，但是模型却很简陋。所以呢，不管是OSI模型及其协议，还是TCP/IP模型和协议，都不完美。然后在后来互联网的发展中，就吸收了OSI模型的优点，进行简化，并结合TCP/IP的协议，继续发展了。 71 | #### 相关参考: 72 | 73 | 《计算机网络》 wiki 74 | 75 | --- 76 | * 文章编写人: Samray 77 | * 最近更新时间: 2016-4-17 78 | -------------------------------------------------------------------------------- /link/0002.md: -------------------------------------------------------------------------------- 1 | #REST API互联网软件架构 2 | * 阅读难度：低 3 | 4 | ## Mobile-First/Web-First Or API-First？ 5 | * 在讨论REST API之前，我想首先讨论一下以下两种开发模式 6 | 1. Mobile-First/Web-First：界面逻辑、业务逻辑先行 7 | 2. API-First：API先行，前后端开发前共同设计好合适的API 8 | * 我认为，Mobile-First/Web-First在前后端默契配合较强的情况下，能够提高开发效率，但是缺点也很明显，后台不知道前端需要什么数据，前端也不知道后台API怎样设计。就iOS移动前端而言，每次联调接接口会需要消耗较多的时间。而API-First虽然前期设计API会耗费一定的时间，但是能够大幅度的减少联调所消耗的时间，同时也降低迭代难度。所以我认为应该首选API-First 9 | 10 | ## REST API 11 | * 定义：REST API是一套目前比较成熟的互联网应用程序API架构设计理论。个人理解：REST API/RESTFul API是面向资源的，它能够让你一眼看到URI、HTTP Methods、HTTP Status Code，就知道接下来要干什么。 12 | * 历史故事：REST这个词是由HTTP 1.0/1.1协议主要设计者、Apache服务器软件作者之一的Roy Thomas Fielding在他的博士论文 "Architectural Styles and the Design of Network-based Software Architectures"中首次提出的。他这篇博士论文主要的写作目的是：在符合架构原理的前提下，得到一个功能强、性能好的、适宜通信的架构。他把他对互联网软件的架构名定为：REST（Representational State Transfer），中文译名：“表现层状态转移”。 13 | * 表现层：“资源”的“表现层”。资源可以是文本、图片、歌曲、服务等等。我们可以类似指针一样，用URI(统一资源标志符,包含URL(统一资源定位符)与URN(统一资源名称))指向他。访问URI即可获取他的资源，即URI是这个资源的指针。在REST架构中，每个资源都应该具有唯一标识URI。资源呈现出来的具体形式，称作资源的“表现层”。在某个程度上。这个“表现层”可以理解为它的格式，比如一张照片，BMP格式、JPG格式、PNG格式分别是它的不同表现层。（其中，“表现层”在HTTP Header信息中用Accept及Content-Type描述） 14 | * 状态转移：在客户端与服务器互动过程中，数据与状态的转化。如HTTP协议中的GET、POST、PUT、DELETE是客户端用到的状态转化的手段。在REST架构中，我们应该使用标准的方法来改变资源的状态，即对于同一个地址，采用POST/GET/其他方法会跳转到不同的URI从而获取不同的资源。 15 | 16 | ## REST六大架构约束准则 17 | * REST API六大架构约束准则： Client-Server、Stateless、Cache、Uniform Interface、Layered System、Code-on-Demand 18 | * 客户 - 服务器通信：通信只能由客户端发起,客户端与服务端分离 19 | * 无状态：通信的会话状态由客户端维护 (即不记录客户端当前页码/状态信息) 20 | * 有缓存： 响应内容可以在通信链的某处被缓存（一般而言，由客户端进行缓存） 21 | * 统一接口：通信链组件之间通过统一的接口相互通信(即Web端与移动端接口应尽量保持一致) 22 | * 分层系统：通过限制组件的行为，每个组件只能看到与它交互的“邻居”。（即引入中间层） 23 | * 按需代码(可选)：支持通过下载并执行一些代码，对客户端功能进行扩展 24 | 25 | ## 其他补充准则 26 | * HTTP GET && HEAD方法应该总是安全的，eg: 27 | 28 | GET /deleteNews?id=1 29 | 不应该被搜索引擎搜索得到 30 | * 采用分页机制，每一页应具有指向上一页、自己、下一页的超文本链接，eg: 31 | 32 | 指向上一页： 33 | 指向自己： 34 | 指向下一页： 35 | 36 | * URI应该使用名词复数，动词动作应尽量用标准的HTTP协议的方法表示 37 | * 错误 38 | 39 | POST http://www.mooapp.com/mouzhi/recruitment/addrec 40 | 41 | * 正确 42 | 43 | POST http://www.mooapp.com/mouzhi/recruitments 44 | 45 | * 一些REST API的设计例子 46 | 47 | GET /newlists/ID/title：获取某篇新闻的title 48 | GET /newlists：列出含有所有新闻的新闻列表 49 | POST /newlists/news：新建一篇新闻 50 | DELETE /newlists/ID：删除某篇新闻 51 | PUT /newlists：客户端提供改变后的完整的新闻列表信息，并更新后台的新闻列表信息 52 | PATCH /newlists：客户端只提供改变后的那一部分的新闻列表信息，更新后台的新闻列表信息 53 | 54 | * 关于版本：URI中可包含版本号，亦可将版本号放在HTTP Header中的Accept字段进行区分 55 | * 放在URI中, eg: 56 | 57 | http://www.mooapp.com/version2 58 | 59 | * 放在Accept字段, eg: 60 | 61 | Accept: vnd.mooapp-com.getNews+json; version=2.0 62 | 63 | * 关于域名:API应尽量放在主域名内，eg： 64 | 65 | http://api.mooapp.com 66 | http://www.mooapp.com/api 67 | 68 | * API的设计应该存在冗余，即统一资源可被多重描述，eg: 69 | 70 | GET /newlists/ID/title 71 | 72 | 应该等价于 73 | 74 | GET /title?newlists_id=ID 75 | 76 | 以上两种方式都应该能够访问到相应数据 77 | 78 | * 关于状态 79 | * HTTP链接是无状态的，即不记录每个链接的信息 80 | * Rest传输包含状态信息，即每个细分Api都应该包含返回的状态码与提示信息： 81 | * 常见的HTTP状态码： 82 | * 1xx：请求已被接受，正在继续处理，此为临时状态码 83 | * 200：请求成功 84 | * 3xx：重定向状态码,代表客户端需要进一步操作，服务端应该给予客户端重定向的后续请求地址 85 | * 401：用户没有权限 86 | * 404：用户请求不存在的记录，服务器没有做任何操作 87 | * 500：服务器发生错误 88 | 89 | > [WIKI - HTTP状态码](https://zh.wikipedia.org/wiki/HTTP状态码) 90 | 91 | * 包含Hypermedia API 92 | * 对于1xx/3xx状态，最好提供下一步的链接 93 | * eg: 94 | 95 | { 96 | "current_user_url": "https://api.github.com/user", 97 | "authorizations_url": "https://api.github.com/authorizations" 98 | } 99 | 100 | * 身份认证应该采用OAuth框架 101 | * 对于移动客户端，应尽量采用JSON格式，以加快传输速率以及降低流量消耗(JSON文件较XML小) 102 | * API应该提供易于测试的数据 103 | 104 | ## REST API优点 105 | * 可利用的缓存提高响应速度 106 | * REST的软件依赖性小 107 | * 由于合理的API设计，REST的扩展性迭代性更强 108 | * 由于HTTP链接无状态，可以让不同的服务器处理一系列请求中的不同请求，提高服务器扩展性 109 | 110 | ## 补充 111 | * REST与RESTful：RESTful API意味着实现了REST/REST-like的架构 112 | 113 | --- 114 | > ## 参考资料 115 | 1. [REST出处论文 - CHAPTER 5 -Representational State Transfer](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) 116 | 2. [Comparing API-First to Mobile First](http://www.api-first.com/blog/comparing-api-first-to-mobile-first.html) 117 | 3. [REST API例子 - LeanCloud](https://leancloud.cn/docs/rest_api.html) 118 | 4. [Principles of good RESTful API Design](https://codeplanet.io/principles-good-restful-api-design/) 119 | 5. [REST best practices](https://bourgeois.me/rest/) 120 | 6. [iOS - RESTKit](https://github.com/RestKit/RestKit) 121 | 7. [Rails - REST](http://www.jikexueyuan.com/course/741_2.html) 122 | 123 | --- 124 | 125 | * 文章更新时间：2016.4.7 126 | * 作者：Seahub 127 | -------------------------------------------------------------------------------- /link/0003.md: -------------------------------------------------------------------------------- 1 | # 物理层 2 | * 阅读难度 中等 3 | * 上一篇博文我们谈到了两个重要的网络体系结构,现在我们来谈网络协议最底层的物理层 4 | ，这一层定义了比特作为信号在信道时发送相关的电气，时序和其他的接口，物理层是构建网络的基础 5 | 6 | ## 基础知识 7 | 我们先来谈谈相关的基础知识 8 | 9 | #### 带宽 10 | 这里说的带宽跟我们平时认识到的带宽不太一样，平时的带宽是指一个信道的最大数据速率，以每秒多少个 11 | 比特来衡量，通俗来说，就是我们平时经常谈论，家里的带宽是多少，10M还是更多 12 | ，但是这里的带宽的意思又是不一样了。 13 | 14 | > 在传输介质中，在0到某个频率F这段范围内，振幅在传输的过程中都不会衰减(即，传输的信号不会发生变形) 15 | ，而在F之上的频率都会有不同程度的衰减，这段不会衰减的频率就叫做带宽了 16 | 17 | #### 信噪比 18 | 因为分子大量的无规则运动，所以随机(热)噪声总是存在的。热噪声的数量可以用信号功率与噪声功率的 19 | 比值来衡量的，这样的比值叫做信噪比。我们将信号功率记作S，噪声功率记作N，那么信噪比就是S/N 20 | 21 | ### 数据通信理论 22 | 23 | ##### 尼奎斯特定理(Nyquist 又叫做采样定理) 24 | 25 | ###### 最大数据速率C=2Wlog2N 26 | (W是指信道的带宽，N是指信号包含的N个离散等级，既是电平强度，例如，我们传输 27 | 二进制数据，N就是2) 这是理想情况下的数据传输情况，即这是一条无噪声的信道，但是即使是理想情况下， 28 | 信道传输能力也是有限的, 29 | 注意这里的log2是以2为底的对数。 30 | 31 | * 但是，我们必须认识到，理想的条件是没有可能存在的，无论怎样，噪声都是存在的， 32 | 所以采样定理在存在随机噪声的情况下就不太适合了 33 | 这个时候，另外的一个人就提出了一个有噪声的信道的情形下的理论 34 | 。在介绍这个理论之前，我想先介绍一下这个人，他就是克劳德·艾尔伍德·香农（Claude Elwood Shannon，1916年4月30日－2001年2月26日） 35 | ，美国数学家、电子工程师和密码学家，被誉为信息论的创始人。香农是密西根大學學士，麻省理工學院博士。 36 | 1948年，香农发表了划时代的论文——通信的数学原理，奠定了现代信息论的基础 37 | 。不仅如此，香农还被认为是数字计算机理论和数字电路设计理论的创始人 38 | 。1937年，21岁的香农是麻省理工學院的硕士研究生，他在其硕士论文中提出，将布尔代数应用于电子领域 39 | ，能够构建并解决任何逻辑和数值关系，被誉为有史以来最具水平的硕士论文之一 40 | 他在通信领域的地位就相当与图灵 冯诺依曼在计算机学科的地位，都是神一般的存在 41 | 。那么现在我们就来学习一下香农定理 42 | 43 | ##### 香农定理 44 | 45 | ###### 最大比特率 Rmax=W*log2(1+S/N) 46 | (W是指信道的带宽，N是指信号S/N是指信噪比)，注意这里的log2是以2为底的对数。 47 | 这条结论告诉我们实际通信能获得的最大容量,《计算机网络》中举过一个例子：在普通的电话线上提供访问 48 | Internet的ADSL（Asymmetric Digital Subscriber Line 非对称数字用户线路）使用了大约1MHz的带宽。 49 | 线路上信噪比的程度取决于住宅和电话交换局之间的距离，对于1～2km的短距离来说，40分贝的信噪比算是很好的状况了。正是因为电话线这样的特性，所以无论怎样，永远没可能在获得高于13Mbps的数据率。实际上，ADSL的 50 | 最高速率为12Mbps，虽然用户看到的速率比这个要低很多。但这个数据实际上已经是很好了。 51 | 52 | #### 小结 53 | 对于软件更感兴趣的我来说，学习物理层真的有点困难，因为这里涉及到更多的是通信还有电子方面的知识， 54 | 不过我感觉物理层最重要的是这两个数据传输的理论基础。因为理论通了，带动的是一大片的实际应用，事实也是这样。 55 | 理解了尼奎斯特-香农定理以后，物理层的其他东西就不太难了，剩下要学习的就是数据传输介质，无线传输 56 | ，通信卫星等通信手段了，还有数字调制和多路复用等相关提高提高已有传输介质利用效率的技术了。 57 | 58 | --- 59 | * 文章编写人: Samray 60 | * 最近更新时间: 2016-4-17 61 | -------------------------------------------------------------------------------- /link/0004.md: -------------------------------------------------------------------------------- 1 | # 传输层之TCP协议 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 5 | * 传输层定义：传输层将用户应用程序的数据交由网络层分包，并通过路由传输到执行机器的进程。同时传输层从网络层接受的数据重新组合交由上层应用程序操作 6 | * 传输层是否有必要存在？ 7 | * 我们知道，网络层的分组是不可靠的，我们没有办法知道数据什么时候到达，甚至是否到达。我们不能保证分组报文不丢失且没有错误地按顺序传输。一言以蔽之，传输层的出现就是因为网络层“不够用”。因此，我们需要一层特殊的层，用来进行恢复工作。这层就是传输层。 8 | * 接下来的连续三周我将为大家介绍传输层中的相关协议 9 | 10 | ## TCP(Transmission Control Protocol) - 传输层控制协议 11 | * TCP协议是面向连接的，可靠的、基于字节流的通信协议。TCP提供全双工工作模式，即数据可在同一时间双向传输。TCP层具有发送缓存和接收缓存的能力，以此来临时存储数据。 12 | * TCP协议工作流程简述： 13 | 1. 应用层向发送端实体的TCP层发送数据流 14 | 2. 发送端实体的TCP层把数据流分区成适当长度的报文段，并给每个包一个序号 15 | * 分区成适当长度：方便传输，长度受该计算机连接的网络的数据链路层的最大传输单元的限制 16 | * 给每个包一个序号：保证不丢包，且保证按序接受 17 | 3. 发送端实体的TCP层把处理后的结果传送给IP层 18 | 4. IP层通过网络传送给接收端实体的TCP层 19 | 5. 接收端实体的TCP层对已成功收到的包发回一个相应的确认（ACK） 20 | 6. 发送端实体的TCP层在合理的往返时延内未收到ACK包，则判断为已丢包，需重传 21 | * TCP用一个校验和函数来检验数据是否有误，在发送和接受的时候都要计算校验和 22 | 23 | * TCP完整运作方式 24 | 1. 三路握手创建通路连接 25 | * 流程理论 26 | 1. 两端初始化序号等参数，客户端打开一个socket监听服务器端的连接 27 | 2. 服务器打开（被动打开） 28 | 3. 服务器端打开后，用户端创建连接（主动打开） 29 | * 流程简述 30 | 1. Client -> Server(SYN，主动打开)，SYN包序号为随机数A 31 | 2. Server -> Client（SYN-ACK,发送的ACK = A + 1),SYN-ACK包序号为随机数B 32 | 3. Client -> Server(ACK，发送的ACK = B + 1)，包序号为收到的确认号A+1，响应则为B+1 33 | 34 | ![TCP创建通路](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/TCPCreate.png?raw=true) 35 | 36 | 2. 数据传输 37 | * 使用序号进行排序（保证按序接收）并检测重复的数据 38 | * 使用校验和来排除错误 39 | * 使用确认和计时器来检测和纠正丢包和延时 40 | 41 | 3. 四路握手终结通路 42 | * 流程理论 43 | 1. 应用进程调用Close，客户端(Client)执行主动关闭 44 | 2. 客户端端发送一个FIN包，表示数据发送完毕 45 | 3. 服务端（Server）接收FIN包后发送ACK包，并对自身执行被动关闭。接收端接收ACK包后进入“等待结束”状态。 46 | 4. 服务端中对应要关闭的进程调用close关闭socket，导致TCP层发送一个FIN包 47 | 5. 客户端发送ACK包确认对服务端FIN包的接收 48 | * 流程简述 49 | 1. Client -> Server(FIN)，FIN包序号为随机数M 50 | 2. Server -> Client(ACK，发送的ACK = M + 1) 51 | 3. Server -> Client(FIN)，FIN包序号为随机数N 52 | 3. Client -> Server(ACK，发送的ACK = N + 1) 53 | 54 | ![TCP终结通路](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/TCPClose.png?raw=true) 55 | 56 | * TCP与UDP区别 57 | 1. TCP是面向连接的协议，UDP是无连接的协议 58 | 2. TCP可靠，UDP不可靠 59 | 3. TCP保证有序，UDP不保证顺序 60 | 4. TCP通过字节流传输（无界），UDP每一个包都是单独的（有界） 61 | 5. TCP有流量控制，UDP没有 62 | 6. TCP传输慢，UDP传输相对较快 63 | 7. TCP头部较UDP大 64 | 65 | 66 | * 应用：非实时性应用，需要可靠的网络通讯的应用 67 | * FTP(文件传输系统) 68 | * HTTP(超文本传输协议) 69 | * SMTP(简单邮件传输协议) 70 | 71 | --- 72 | ## 延伸阅读 73 | 1. [UDP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0006.md) 74 | 2. [QUIC协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0008.md) 75 | 76 | ## 参考阅读 77 | 1. [TCP - Wiki](https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE) 78 | 2. [TCP数据包结构详解1](http://blog.csdn.net/prsniper/article/details/6762145) 79 | 2. [TCP数据包结构详解2](http://www.chnlanker.net/jie-du-tcp-udp-shu-ju-bao-er-tcp-shu-ju-bao-jie-gou.html) 80 | 81 | 82 | --- 83 | 84 | * 文章更新时间：2016.4.14 85 | * 作者：Seahub 86 | -------------------------------------------------------------------------------- /link/0005.md: -------------------------------------------------------------------------------- 1 | # 浅谈数据链路层01 2 | * 阅读难度:低 3 | 4 | ### 前言 5 | 记得上个星期，我们聊了一下网络体系结构的最低层--物理层，那么现在，我们就来谈一下物理层的 6 | 上一层--数据链路层 7 | 8 | 数据链路层不同于物理层，物理层关注的只是单个比特的传输，而数据链路层更多的是注重如何实现两台机器之间有效可靠完整信息块的(称为帧)的通信 9 | ### 数据链路层的服务 10 | *** 11 | * 数据链路层使用物理层提供的服务在信道上传输和接收比特，同时还要提供相应的服务: 12 | * 包括向网络层提供定义良好的服务接口 13 | * 处理传输错误(其他更高的层次也会进行) 14 | * 控制数据流的传输，保证接收方不会被过多的数据淹没而造成丢包 15 | * 数据链路层从网络层获得数据包，然后将这些数据包拆分，封装成帧(frame)。每一个帧都包含一个帧头，一个有效负荷(用来保存数据包),还有一个帧尾 16 | 17 | 18 | ![数据包和帧的关系](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/relationship.png) 19 | 20 | 21 | * 数据链路层可以为网络层提供各种不同的服务。实际提供的服务可能因为具体的协议不同而有差异，一般情况下都可以提供以下三种服务： 22 | * 无确认的无连接服务 23 | * 有确认的无连接服务 24 | * 有确认的有连接服务 25 | 26 | *** 27 | * 无连接服务是指源机器向目标机器发送独立的帧，目标机器并不对这些帧进行确认。以我们的生活常识来理解就是，这个就跟我们去邮局邮递信件那样，我们写好收信人地址，然后把信件寄出去，但是我们寄出去的信件到底发生了什么，我们就不得而知了 28 | 29 | * 有确认连接就是当你向上层提供这种服务的时候，依然没有建立逻辑连接，但是发出的每一帧数据，我们都需要单独确认。这样的的话，源机器发出了数据，就可以知道发的数据是否到达目标机器，没有收到确认的信息的话，就需要重新发送。这个就跟我们寄快递很相似了，我们寄出去的快递我们没办法知道发生了什么，但是我们可以根据接收的朋友的信息来判断是否快递是否成功到达 30 | 31 | * 有确认的有连接服务即需要在源机器和目标机器进行数据传输之前，要先建立一个连接，连接上发送的每一帧都会被编号，数据链路层确保发出的每个帧都会被接收方接收到，而且还是只接受一次。因此，根据我们的描述，我们可以知道，我们相当于为网络层提供了一个有效的比特流。有确认的有连接服务必须经历三个阶段 32 | 1. 建立连接，并进行各种必要准备的初始化 33 | 2. 进行真正的数据传输 34 | 3. 断开连接，释放资源 35 | 36 | * 这种服务就跟我们电话系统很相似了，每次我们要打电话，都是要先拨通朋友的号码，然后进行通话，最后聊完了,我们就要挂电话了 37 | 38 | ### 差错控制和纠正 39 | 正如我们前面所提及的，在信道进行比特传输的过程中，肯定是会有各种干扰的,在各种的干扰之下，信道传输数据 40 | 就肯定会发生传输错误了。那么对于发生的错误，我们应该怎么办呢? 41 | 42 | 现在比较通用的是两种错误处理策略，一种是使用纠错码，另外一种是使用检错码。 43 | ##### 纠错码 44 | 纠错码，顾名思义，就是用来纠错嘛。主要的思想是在每一个发送的帧里面添加足够多的冗余信息，以便接收方可以推算出被发送的数据究竟是什么。 45 | ##### 检错码 46 | 检错码，就是在发送数据的时候，也添加一定的冗余信息，然后让接收方判断传输数据的过程是否发生了错误，如果出错了，那么就请求发送方重新发送 47 | 48 | 检错码和纠错码是分别应用于不同的情形的，例如检错码就是应用与高度可靠的信道(例如光纤)，因为出错的 49 | 概率很小，出错了，就叫发送方再发一遍就可以了。但是纠错码的情况就是不一样了，在一些发生错误概率较高 50 | 的信道，例如(无线链路)，你使用检错码也是于事无补，即使你知道发生错误，请求再发一遍，还是出错，那 51 | 应该怎么办呢。所以这个时候就应该使用纠错码了，通过纠错码还原发送出错的数据块，毕竟，人还是要靠自己的 52 | 53 | *** 54 | ### 结语 55 | 更多有关纠错码和检错码的内容，我会在下星期进行探讨的。 56 | 57 | *** 58 | * 文章编写人: Samray 59 | * 最近更新时间: 2016-4-17 60 | 61 | -------------------------------------------------------------------------------- /link/0006.md: -------------------------------------------------------------------------------- 1 | # 传输层之UDP协议 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 5 | * 关于UDP协议传输，在某些方面其实与IP协议传输很类似。在某种程度上，可以把UDP协议看作是IP协议暴露在传输层的一个接口。那么为什么我们不直接使用IP协议而要用UDP协议进行传输呢？主要原因是因为IP协议中没有“端口”这一个概念。IP协议通过IP地址进行“主机”与“主机”的对话。而UDP协议则通过IP地址 + 端口进行“主机进程”与“主机进程”的通信。 6 | 7 | ## UDP(User Datagram Protocol) - 用户数据报协议 8 | * UDP协议是面向报文的、无连接的、不可靠的、缺乏拥塞控制的传输层协议。UDP不提供数据包分组、组装且不能对数据包进行排序。 （一般而言，使用UDP协议的数据传输顺序检测由应用层负责）。在网络质量较差时，UDP协议数据包丢失较为严重。 9 | * 由于UDP提供的控制选项较少，故包头较TCP小，在数据传输过程中延迟小、数据传输效率高。理论上，流量消耗也相对较小。因此UDP适合对可靠性要求不高的应用程序，或由应用层保障可靠性的应用程序。 10 | * 由于UDP协议不建立连接，因此没有所谓的“连接状态”，一台服务器可同时向多个客户传输相同的消息 11 | 12 | * UDP Helper：实现对指定UDP端口广播报文的中继转发，将指定的UDP端口的广播报文转换为单播报文发送给指定的服务器，起到中继的作用 13 | ![UDP Helper](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/UDP%20Helper.jpg?raw=true) 14 | * UDP报头十分简单，由四个域组成，每个域占用16位，如下： 15 | ![UDP Header](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/UDP%20Header.jpg?raw=true) 16 | 17 | * UDP协议工作流程简述： 18 | 1. 获得目标的IP地址及端口号 19 | 2. 应用层向发送端的实体UDP层发送数据流 20 | 3. 发送端实体的UDP层通过特殊算法（一般而言是16bit字的二进制反码和）计算出数据的校验和 21 | * 校验和：用于保证数据安全 （UDP协议校验可选（校验码字段为0时表示无需校验）。但对于TCP协议，必须就行校验）。当接收方校验和不匹配时，只是进行丢包/提供警告信息，而不进行错误校正。 22 | 4. 进行数据传输 23 | 5. 接收端实体的UDP层通过特殊算法计算校验和，计算后检测是否一致 24 | 6. 接收端实体根据端口号将数据传送至相应应用 25 | ![UDP](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/UDP.png?raw=true) 26 | * 应用：可靠性可由应用层保障的应用程序/对可靠性要求不高的应用程序 27 | * 音频传输 28 | * 视频传输 29 | * 文件传输 30 | * DNS(域名系统) 31 | * TFTP（简单文件传输系统） 32 | 33 | --- 34 | ## 延伸阅读 35 | 1. [TCP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0004.md) 36 | 2. [QUIC协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0008.md) 37 | 38 | ## 参考阅读 39 | 1. [关于校验和算法的讨论](http://blog.csdn.net/li_xiang1102/article/details/6901660) 40 | 2. [WIKI - UDP](https://zh.wikipedia.org/zh-tw/%E7%94%A8%E6%88%B7%E6%95%B0%E6%8D%AE%E6%8A%A5%E5%8D%8F%E8%AE%AE) 41 | 42 | 43 | --- 44 | 45 | * 文章更新时间：2016.4.20 46 | * 作者：Seahub 47 | -------------------------------------------------------------------------------- /link/0007.md: -------------------------------------------------------------------------------- 1 | # 浅谈数据链路层02 2 | * 阅读难度 低 3 | * 记得上个星期我们谈论了链路层的一些基本内容，我们今天就来谈论一下纠错码和检错码 4 | 5 | ## 纠错码 6 | * 海明码 7 | * 二进制卷积码 8 | * 里得所罗门码 9 | * 低密度校验码 10 | 11 | 为了实现纠错的功能，我们都要在待发送的信息里面添加冗余信息。一帧通常由m个数据位（有效数据） 12 | 和r个冗余位（校验）组成。根据数据位和校验位不同的组成方式，又可以把纠错编码分为以下几种 13 | * 块码 ：r个校验位是作为与之相关m个数据位的函数计算出来的，就像在一张大表中找到m位数据位对应的 14 | r位校验位那样 15 | * 系统码： 直接发送m个数据位,然后发送r个校验位，它们之间没有编码关系 16 | * 线性码： r个校验位是作为m个数据位的线性函数计算出来的 17 | 18 | 根据纠错码的使用广泛程度，我们还是谈谈使用得最广泛的卷积码和罗德所罗门码 19 | ### 卷积码 20 | 在卷积码中，编码器处理一个输入位序列，并生成一个输出位序列，输出取决与当前的输入和以前的输入，所以 21 | 决定当前输出的以前输入位数称为代码的约束长度 22 | 23 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/correct_code1.png) 24 | * 如果输入序列为111，输入序列会进入编码器的寄存器(register,简称reg),每一个寄存器都会储存一个输入单元 25 | ，而它们的初始值都是0。如图，编码器有3个模2加法器（相当于异或门），运算后，寄存器的 26 | 值会后移一格，然后继续将信息传至输出端，这样就可以得到想要的传输的内容了 27 | output1=reg.1+reg.3 28 | output2=reg.1+reg.2+reg.3 29 | 因为数据是依据输入到编码器的，所以3个寄存器的储存信息分别是：reg1是目前输入数据，reg2是上次 30 | 输入的数据，reg3是上上次输入的数据。 31 | 卷积码的解码过程是针对一个输入序列，找出最有可能产生的输出位序列(包括任何错误)，对于较小的约束长度 32 | k，用Viterbi开发的算法逐个检查观察到的序列，记住每一步的和输入序列的每个可能内部状态，即输入序列 33 | 产生观察序列可能产生的错误，最终其中那个具有最少错误的输入序列就是最有可能的消息。 34 | 35 | ### 里得所罗门码 36 | 里德所罗门码基于这样的一个事实的，每个n次多项式是由n+1点确定的。例如，一条具有ax+b形式的线 37 | 是由2个点所决定。同一条线上的其他点都是冗余的，这个就有助于我们纠错了， 38 | 可以想象有两个数据点代表一条线，并且我们给这两个数据点额外加上两个校验点，该两个校验点选自同一条线 39 | ，如果收到的其中一个点出现错误，我们仍然可以通过接收点的拟合点来回复这个数据点 40 | 。三个点将处在同一条直线上，而出错的那个点不在这条线上，只要找到这个点，我们就能纠正错误了 41 | 这个就是里德所罗门码的基本实现原理 42 | 43 | ## 检错码 44 | 我们上个星期说到过，纠错码被用于错误率较高的无线链路，那么检错码是用于错误率较低的光纤等可靠链路 45 | ，偶尔出错，通知发送方重传就行了 46 | 有这几种常用的检错码 47 | * 奇偶 48 | * 校验和 49 | * 循环冗余校验 50 | 51 | 我们打算来介绍在链路层使用最广泛的检错码，循环冗余校验码（CRC,Cyclic Redundancy Check） 52 | CRC码是由两个部分组成，前部分是信息码，就是需要校验的信息，后部分就是校验码 53 | 如果CRC码共长n个字节，信息码长k个字节，就称为(n,k)码，它的编码规则是： 54 | ### 移位 55 | 将原信息码(k字节)左移r位(k+r=n),运用一个生成多项式g(x)也可以看成二进制数，有模2除上面的式子 56 | 得到的余数就是校验码，模2除的真值和模2加一样，就是我们可以理解成异或计算 57 | 58 | 生成多项式应满足的原则 59 | * 生成多项式的最高位和最低位必须是1 60 | * 当被传送信息(CRC)r任何一位发生错误时，被生成多项式做模2除后应该余数不为0 61 | * 不同位发生错误时，应该使余数循环 62 | * 对余数继续做模2除，应使余数循环 63 | 64 | 65 | 在实际应用中,多项式g(x)的取值是有限制的，有以下的国际标准 66 | * CRC-CCITT=x^16+x^12+x^5+1* 67 | * CRC-16=x^16+x^15+x^2+1 68 | * CRC-12=x^12+x^11+x^3+x^2+x+1 69 | 标准还有其他，我就不一一列出来了 70 | 我们觉个例子来说明CRC码吧 71 | #### 例子 72 | 例如：g(x)=x^4+x^3+x^2+1，（7,3）码，信息码110产生的CRC码就是 73 | 11101 | 110,0000（设a=11101 ，b=1100000） 74 | 对于g(x)=x^4+x^3+x^2+1的解释：（都是从右往左数）x4就是第五位是1，因为没有x1所以第2位就是0 75 | 用b除以a做模2运算得到余数：1001 76 | 余数是1001，所以CRC码是1001，传输码为：110,1001 77 | 78 | --- 79 | * 文章编写人: Samray 80 | * 最近更新时间: 2016-4-24 81 | -------------------------------------------------------------------------------- /link/0008.md: -------------------------------------------------------------------------------- 1 | # 传输层之QUIC协议 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 5 | * QUIC是一个由Google开发的协议。QUIC类似于SPDY，以及2011年面世的TCP Fast Open，但是SPDY是一个实验性的传输层协议，而QUIC则是一个工作在传输层的协议。我个人认为，Google之所以推出QUIC，一方面是因为单独的UDP虽然速度快，但得不到可靠性的保证，而TCP传输的负担较重，两者之间需要一定的折衷角色出现，而QUIC则是充当了这个角色来将UDP和TCP的优势结合起来。另一方面则是因为TCP+TLS、TCP Fast Open等新技术被部署的十分缓慢，而TCP Fast Open也没有被大范围使用。相对而言，QUIC部署在客户端级别，而非内核级别，这样能够以更快的速度进行迭代和更新。QUIC主要优化对象是使用TCP连接的Web应用程序。我们可以在chrome://flags中打开实验性QUIC协议的选项(据说国内只要DNS没有被污染，打开QUIC功能，重启后，即可“自带翻墙”，可正常使用Google服务) 6 | 7 | ![chrome-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/chrome-1.png?raw=true) 8 | 9 | * SPDY简介：由Google开发，一种基于TCP的应用层用于发送网页内容协议。SPDY通过优先级和多路复用，使得只需要创建一个TCP连接即可传输多种资源，降低了网页的加载时间。 同时SPDY广泛应用了TLS加密，并对传输内容进行了压缩，使得传输时间变短 10 | * TCP Fast Open简介： 通过TCP握手开始时的SYN包中的TFO Cookie来验证之前连接过的Client，若验证成功，则在TCP三次握手最终ACK包收到之前发送数据，即跳过了一个绕路行为。每当客户端连接时，这个Cookie都会被重复返回，然后存储在客户端中，该功能同样能在chrome://flags中打开（针对某些平台） 11 | 12 | ![chrome-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/chrome-2.png?raw=true) 13 | 14 | ## QUIC(Quick UDP Internet Connections) - 快速UDP网络连接 15 | * QUIC特点与优势（拥有SPDY的所有优点） 16 | * 单连接下，基于UDP的多路传输：通过一个连接同时进行多个请求，不必同时建立若干连接浪费资源 17 | * 相对TCP三次握手方式，等待时延较低：如果之前已经连接过，则无需做类似TCP的握手，即可直接传送数据，连接建立时延为0 18 | * 前向纠错：相对于TCP采用的重传机制，QUIC采用纠错机制：将N个包的校验和建立成一个单独的数据包发送，这样如果在这N个包中丢了一个包可以直接恢复，减少重传耗费的时间 19 | * 连接保持：在IP地址和端口变化的情况下，可以无需重新连接，继续保持通信。即从Wi-Fi切换到流量，可以无需等待，减少了用户等待时间 20 | 21 | ![Yesky-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/Yesky-1.png?raw=true) 22 | 23 | ![Yesky-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/Yesky-2.png?raw=true) 24 | 25 | --- 26 | ## 延伸阅读 27 | 1. [TCP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0004.md) 28 | 2. [UDP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/0006.md) 29 | 30 | ## 参考阅读 31 | 1. [Google Develop Live介绍视频](https://www.youtube.com/watch?v=hQZ-0mXFmk8) 32 | 2. [天极新闻 - 谷歌欲用改良版的UDP协议QUIC提高网页速度](http://news.yesky.com/220/59050220.shtml) 33 | 3. [QUIC论文](http://c3lab.poliba.it/images/3/3b/QUIC_SAC15.pdf) 34 | 4. [QUIC加密](https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit) 35 | 36 | --- 37 | 38 | * 文章更新时间：2016.4.27 39 | * 作者：Seahub 40 | -------------------------------------------------------------------------------- /link/0009.md: -------------------------------------------------------------------------------- 1 | ## 今天不谈协议--来聊聊实践之如何搭建DNS服务器 2 | * 阅读难度 低 3 | 4 | #### 前言 5 | * 本来，今天我是打算继续来聊聊链路层的相关协议的，但是我今天用了大半天的研究DNS的服务器搭建。所以我决定，今天先不聊链路层了，来说一些应用层的实践，可能跳跃性有点大，不过我只是比较随性啦。好咯，言归正传，为什么我会没事自己去折腾DNS服务器呢，原因很简单，是因为那堵伟大的墙DNS污染，有时候请求被重置，我觉得很不爽，所以我觉得我自己要做点什么。 6 | 7 | #### 介绍 8 | * 只是先简介一下，更多详细的东西我想到了应用层就再和大家一起探讨，DNS(Domain Name System) 9 | 就是域名解析系统。很通俗的理解就是，我们人类的记忆力是比不上计算机的，但是我们要上网的，要输入我们想去的网站的网址的，如果我们记得是ip,简短的我们可能能记着，但是想去的网址多了，那应该怎么记阿，这个时候有人提出想法，不如我们人就记住域名，然后把域名和相应的IP对应上，那我们就能输入我们人类能记住的字符网址，然后转换成IP，就能访问了，例如我们很熟悉的百度，IP是220.181.57.217，但是我们 10 | 输入 www.baidu.com就能找到这个IP ，靠的就是DNS了 11 | 12 | #### Caching DNS Server 13 | * 我们首先要配置的就是Caching DNS Server,直译为DNS 缓存服务器，顾名思义，这种服务器主要的功能是递归处理客户端请求和进行缓存，那么缓存什么呢，就是在一定时间内缓存查询到的DNS 结果了，然后把结果在传到请求的客户端，所以呢，它一般是直接处理请求的，或者是去找其他的DNS服务器的 14 | 15 | #### Forwarding DNS Server 16 | * 我想配置的第二种是Forwarding DNS Server ，就是DNS转发服务器，Forwording DNS Server 可以看作几乎和 17 | 缓存服务器相同，不过他们的工作方式就很不一样了。转发DNS服务器只是转发请求，它不会自己处理递归请求的，就是只能发送单个请求，这对那些带宽有限的的信道就很好了 18 | 19 | ### 服务器 20 | #### 实操 21 | * 服务器我用的是Debian 系列的，如果是RHEL系列，只是包管理工具还有文件位置有点差别而已。我最后会说一下 22 | 的。正式开始之前我们要做一些准备工作 23 | 24 | ##### 准备工作 25 | 首先，有一台服务器,然后 26 | 我们要先安装一个叫bind的软件 在终端输入 : 27 | 28 | sudo apt-get update 29 | sudo apt-get install bind9 bind9utils bind9-doc 30 | 31 | 安装完之后我们就先配置Caching DNS Server 32 | 首先 进入到/etc/bind 目录 33 | 34 | cd /etc/bind 35 | 36 | 我们就先不管里面的文件究竟是什么了，用到的文件我们在去聊聊 37 | 里面主要的配置文件是named.conf ，而这个文件呢，又是来源于其他三个文件的 38 | 分别是: 39 | 40 | * named.conf.options 41 | * named.conf.local 42 | * named.conf.default-zone 43 | 44 | 现在我们是要配置DNS缓存服务器，所以只要改named.conf.options这个文件就行了 45 | 46 | sudo nano named.conf.options 47 | 48 | 如果是Centos系列就修改/etc/named.conf 49 | 50 | sudo nano /etc/named.conf 51 | 52 | options { 53 | directory "/var/cache/bind"; //DNS 数据库默认放置的目录所在 54 | allow-query { any; }; //是否允许查询，any代表任何人都可以用这个dns服务器查询 55 | recursion yes //是否可以递归查询 56 | dnssec-validation auto; 57 | auth-nxdomain no; # conform to RFC1035 58 | listen-on-v6 { any; }; 59 | };` 60 | 61 | 这个就是基本的Caching dns配置了 62 | 63 | 下面的就是Forwarding DNS Server 64 | 65 | options { 66 | 67 | directory "/var/cache/bind"; 68 | recursion yes; 69 | allow-query { any; }; 70 | dnssec-enable yes; 71 | dnssec-validation yes; 72 | forwarders { 73 | 8.8.8.8; 74 | 8.8.4.4; 75 | }; 76 | forward only; 77 | 78 | dnssec-validation auto; 79 | auth-nxdomain no; # conform to RFC1035 80 | listen-on-v6 { any; }; 81 | }; 82 | 83 | 84 | 8.8.8.8、8.8.4.4都是谷歌的公共服务器的IP地址，我们现在就用这谷歌的IP地址，基本的配置弄完了，我们就来试试一下 85 | 86 | sudo named-checkconf 87 | 88 | 检查一下配置文件的语法，如果没有输出，那就是好的结果了，然后我们继续咯 89 | 90 | sudo service bind9 restart 91 | 92 | 重启bind9的服务 93 | 94 | *** 95 | 96 | ### 客户端 97 | 客户端我默认也是debian系列的OS ，在终端里面输入 98 | 99 | sudo nano /etc/resolv.conf 100 | 101 | nameserver 192.0.2.1(这里输入你的DNS服务器的IP) 102 | 103 | #nameserver 8.8.4.4 104 | 105 | #nameserver 8.8.8.8 106 | 107 | #nameserver 209.244.0.3 108 | 109 | 保存之后，现在就是测试了 110 | 111 | dig linuxfoundation.org 112 | 113 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/cmd.png?raw=true) 114 | 115 | 看到这个，就说明我们的服务器解析成功。我们再试一下 116 | 117 | dig linuxfoundation.org 118 | 119 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/cmd2.png?raw=true) 120 | 121 | 看，成功了不过我们的修改关机以后就会重置了，要想永久改变呢，我们就要再改一些配置 122 | Debian 系列： 123 | 124 | sudo nano /etc/network/interfaces 125 | 126 | 127 | . . . 128 | iface eth0 inet static 129 | address 111.111.111.111 130 | netmask 255.255.255.0 131 | gateway 111.111.0.1 132 | dns-nameservers 192.0.2.1(这里放服务器的IP地址) 133 | . . . 134 | 135 | 如果是Centos 系列： 136 | 137 | sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0 138 | 139 | DNS1=192.0.2.1(这是服务器的IP地址) 140 | 141 | ### 总结 142 | * 对于Caching 和Forwording 类型的DNS服务器，当有很多的下层DNS服务器都使用forwarder时，那个被设置 143 | 为forwarder的主机，由于会记录很多的查询信息记录，因此，对于那些下层的DNS服务器而言，查询速度会增加很多 144 | 。但是当主DNS本身的业务量就很繁忙的时候，你的caching 服务器还要向它请求数据，因为原本的数据传输量 145 | 就很大，你还向它请求，数据传输量就太大了，带宽方面可能负荷过大，查询速度就会变慢 146 | 所以，这个就看具体情况了 147 | 148 | --- 149 | 150 | * 文章最近更新时间：2016.5.1 151 | * 作者：Samray -------------------------------------------------------------------------------- /link/000A.md: -------------------------------------------------------------------------------- 1 | # 应用层之SMTP协议 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 5 | * 我们经常收发邮件，我们熟悉每个邮箱的收发操作，但我们是否明白整个收发邮件的过程呢？一封短短的邮件发送背后实际包含着一段不为人知的故事...嗯，接下来这几周我会给大家介绍邮件传输的常用的协议，希望大家共同学习、探讨 6 | * 本周我选择首先要讲的协议是SMTP，SMTP协议处于一个什么样的地位呢。SMTP承担着我们收发邮件中“发”过程的重任，它帮助每台计算机发送\中转邮件时找到下一个目的地。 7 | 8 | ## SMTP(Simple Mail Transfer Protocol) - 简单邮件传输协议 9 | * 部分术语解释 10 | * 用户代理(User Agent):用户与电子邮件系统的交互接口。可以简单理解为我们发送邮件打开的网页客户端/客户端,比如163、Gmail邮箱等Web交互界面以及Outlook、163邮箱大师等客户端 11 | * 邮件服务器（Mail server）:邮件服务器用于发送、接收邮件。目前的邮件服务器一般采用集群服务器的形式工作，即使一台服务器崩溃，与它相连的其他服务器也依旧能继续工作，并接替崩溃服务器的工作。因此现在的邮件服务器一般是7x24小时不间断工作的。所以它可以在任何时候为用户提供邮件服务。 12 | 13 | * 一般的邮件收发过程 14 | 1. 发信人打开用户代理（Gmail、163、QQ Mail）并在用户代理中编辑邮件（填写好收信人邮箱、标题、附件、正文等） 15 | 2. 用户代理提取相关信息并生成一封符合RFC822邮件格式标准的邮件 16 | 3. 用户代理使用SMTP协议将邮件发送到邮件服务器 17 | 4. 邮件服务器经过重重转发，最终将邮件发送到收信人的邮件服务器 18 | 5. 用户代理使用POP3协议从收信人的邮件服务器中取回邮件 19 | 6. 用户代理以恰当的形式解析取回的邮件，最终以合适的形式呈现在收信人邮箱中 20 | 21 | ![SMTP1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/smtp1.gif?raw=true) 22 | 23 | * SMTP工作阶段（用于在邮件服务器） 24 | 1. 建立TCP连接（一般SMTP是建立在TCP/IP上的，且工作在端口25，以保证邮件的可靠性） 25 | 2. 客户端发送HELLO + 发件人邮箱服务器地址 26 | * HELLO：用于检测是否连接成功 27 | 3. 服务器返回250 OK 28 | * 250状态：相应的邮件操作完成 29 | 4. 客户端发送MAIL FROM + 发件人邮箱地址 30 | * MAIL：开始发送邮件的命令 31 | 5. 服务器返回250 + ... 32 | 6. 客户端发送RCPT TO + 收件人邮箱地址 33 | 7. 服务器返回250 + ... 34 | 8. 客户端发送DATA 35 | * DATA:请求发送的命令 36 | 9. 服务器返回354 Enter mail + ... 37 | * 354状态:可以开始邮件输入，以"."结束 38 | 10. 客户端发送邮件标题(Subject: + ...) 39 | 11. 客户端发送邮件发信人地址（From: + ...） 40 | 12. 客户端发送邮件收信人地址(To: + ...) 41 | 13. 客户端发送正文及其他字段 42 | 14. 客户端结束输入(.) 43 | 15. 服务端返回250 + ... 44 | 16. 客户端发送QUIT(退出连接) 45 | 17. 服务端返回221 Bye 46 | * 221状态：服务关闭 47 | 48 | ![SMTP2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/smtp2.jpg?raw=true) 49 | 50 | * SMTP的缺陷 51 | * 没有身份验证，导致容易出现垃圾邮件 52 | * 只能传送7位的ASCII码，在二进制文件上处理的不好 53 | 54 | * 解决办法 55 | * 开发出诸如ESMTP/SMTP-AUTH等扩展方案，但垃圾邮件问题依旧不断 56 | * 开发出MIME标准用于编码二进制文件并使其通过SMTP来传输，目前大多数SMTP服务器都支持8位MIME扩展 57 | 58 | --- 59 | ## 延伸阅读 60 | 1. [POP3协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000C.md) 61 | 2. [IMAP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000E.md) 62 | 63 | ## 参考阅读 64 | 1. [Youtube - SMTP另类介绍](https://www.youtube.com/watch?v=6MSbon29yRM) 65 | 2. [Youtube - 宏观SMTP介绍](https://www.youtube.com/watch?v=tmE9OqjdK7s) 66 | 67 | --- 68 | 69 | * 文章更新时间：2016.5.4 70 | * 作者：Seahub 71 | -------------------------------------------------------------------------------- /link/000B.md: -------------------------------------------------------------------------------- 1 | ## 基本数据链路层协议 2 | * 阅读难度:低 3 | 4 | --- 5 | 6 | * 之前我们谈了数据链路层一些基本内容，那么现在我们就来谈一下数据链路层的基本协议，不过在谈协议之前，我们先来了解一些基本知识. 7 | 8 | ### 基础知识 9 | * to_physical_layer：向物理层发送一帧 10 | * from__physical_layer:在物理层接收一帧 11 | * wait_for_event(&event)：过程调用，标示数据链路层正在等待事情的发生，只有当 12 | 确实发生了什么事情的时候(比如，到达一个帧的时候)，过程才会返回 13 | * boolean :一个布尔类型的值 14 | * seq__nr:一个小整数，用来对帧编号，以便区分不同的帧 15 | * packet：同一台机器上网络层和数据链路层之间，或者是不同机器上的网络对等实体 16 | * 一个帧由4个字段组成:kind,seq,ack,和info. 17 | * kind:指出帧里面是否有数据 18 | * seq和ack分别做用作序号和确认 19 | * 控制帧的info包含一个数据包,控制帧的info没有用 20 | * start_timer 和stop_timer 分别打开和关闭计时器 21 | * start_ack_timer 和stop__ack_timer控制一个辅助计数器 22 | * enable_network__layer和disable_network_layer用在较复杂的协议，在这样的协议，我们不再假设网络层总是有数据要发送。当数据链路层启动网络层后，它就允许网络层在有数据包要发送是中断自己。 23 | 24 | --- 25 | 26 | * 在介绍完基本信息以后，我们就来谈一下协议了。我们今天先来谈一下比较简单的协议。 27 | 28 | ### 有错信道的单工停-等式协议 29 | 我们先假设在这个协议，数据只能单向传输，发送方以高于接收方能处理到达帧的速度发送帧，导致接收方被淹没，然后信道可能会出错。帧可能会被破坏(帧的校验和就发挥作用了)，也可能完全丢失 30 | 31 | 这个就是我们面对的情况了. 32 | 33 | 首先，我们来处理，发送量太大淹没接收方的情况。 34 | 35 | 现在我们可以用比较合理的解决方法，先举一下生活中的例子，假如你去别人家做客，主人太热情了，煮了一桌子的菜，然后还拼命的往你的碗里夹菜，眼看着你的碗就要满了，菜都快要满出来了，你会怎么办。如果是我呢，肯定会跟主人说不要夹了，要掉出来了。 36 | 37 | 对，就是要给给你信息的那个人说，你"吃不过来"。协议也是这样，让接收方给发送方提供反馈信息。接收方将数据包传给网络层后给发送方发回去一个哑帧，实际上这一帧的作用是给发送方一个许可，允许它发送下一帧。发送方在发出一帧之后，根据协议要求，它必须等待一段时间知道确认帧的到达。 38 | 39 | 我们来考虑一下下面的场景 40 | 41 | 1. 机器1的网络层将数据包1交给它的数据链路层。机器2正确接收到该数据包，并且将它传递给机器2的网络层。机器2给机器1发回一个确认帧 42 | 2. 确认帧完全丢失了，它永远也没用可能到达机器1 43 | 3. 机器1的数据链路层最终超时。由于它没有收到确认，所以它(不正确地)认为自己发的数据帧丢失了或者被损坏，于是他再次发送一个包含数据包1的帧 44 | 4. 这个重复的帧也完好无损地到达机器2的数据链路层，并且不知不觉中被传到了网络层。(结果，这个帧重复了，出错了) 45 | 46 | ---- 47 | 48 | 我们现在来讨论一下传输出错的处理方法。 49 | 50 | 对于接收方来说，它需要一种办法能够区分达到的帧是第一次发来的新帧，还是被重传的老帧。为了做到这一点，很显然的一个做法是让发送方在它发送的每个帧头部放上一个序号。然后，接收方可以检查它所接收到的每个帧的序号，由此判断这是个新帧还是重复帧 51 | 52 | 那么问题就来了，我们的序号要设置成几位的呢？答案： 1位 53 | 54 | 我们就来说一下为什么是1位。 55 | 56 | 在发送方，触发发送m+1位的事件是m号帧的确认帧已经按时返回了，也就是说第m-1位的帧也被接收方正确接收了，而且它的确认帧也已经被发送方接收了。所以我们要考虑的是一帧和它前一帧或者下一帧的关系，所以1位序号(0 1)就能解决问题. 57 | 58 | 在任何一个时刻，接收方期望下一个特定的序号。当包含正确序号的帧到来时，它被接收下来并且传到网络层。然后，接收方期待的下一个序号进行异或操作，任何一个到达的帧，若果包含了错误序号，都将作为重复帧而遭到拒绝。不过，最后一个有效的确认帧要被重复，以便发送方最终发现已经被接收的那个帧 59 | 60 | 如果一个协议中，发送方在前移到下一个数据之前必须等待一个肯定确认，这样的协议称为自动重复请求(ARQ,Automatic Repeat Request)或带有重传的肯定确认(PAR，Positive Acknowledgement with Retransmission),这种协议也只在一个方向上传输数据 61 | 62 | 我们就来看一下这个协议的实现咯(当然是C语言的啦) 63 | 64 | ![PAR](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/par.png) 65 | 66 | ### 总结 67 | 我们来聊了一下比较简单的单向协议，但是在大多数实际环境中，往往是需要两个方向上同时传输数据，所以，更多更复杂，更贴合实际的协议，我们下个星期再讨论啦。 68 | 69 | --- 70 | * 文章最近更新时间：2016.5.7 71 | * 作者：Samray 72 | -------------------------------------------------------------------------------- /link/000C.md: -------------------------------------------------------------------------------- 1 | # 应用层之POP3协议 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 5 | * 本周我想要给大家介绍的是POP3协议，上周我们介绍的SMTP协议负责"发"邮件，自然也需要有协议负责“收”邮件。而POP3协议则是其中一个较为重要的“收”邮件协议 6 | 7 | ## POP3(Post Office Protocol - Version 3) - 邮局协议第三版 8 | * 部分术语解释 9 | * POP3的三种状态:验证状态、处理状态和更新状态。当客户端与服务器建立连接时，进行身份验证，此时状态为验证状态；验证成功后，客户端收取邮件，此时状态为处理状态；在发出QUIT命令后，进入更新状态。进入更新状态后，若想要再次收取邮件，需要重新进入验证状态 10 | 11 | * POPD（POP Daemon）:一个运行在邮件服务器上的特殊进程，用于处理与客户端的连接，验证用户账户名及账户密码，如果验证成功，则POP3协议转换至处理状态 12 | 13 | ![POP3 Transform](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/POP3transform.jpg?raw=true) 14 | 15 | * 一般用户在邮件客户端“收邮件”的流程 16 | 1. 在邮件软件设置POP模式、POP服务器URL（eg:pop.163.com）以及用户名、密码 17 | 2. 点击收取邮件按钮 18 | 3. 邮件客户端 -> POP服务器（进行DNS解析） 19 | 4. 邮件客户端 -> POP服务器 110端口(进行TCP连接) 20 | 5. 邮件客户端 <- POP服务器（POP协议验证状态:POPD进程进行认证） 21 | 6. 邮件客户端 -> POP服务器(输入用户名、密码) 22 | 7. 邮件客户端 -> POP服务器(执行STAT命令:请求返回邮箱统计资料（总数、大小）等) 23 | 8. 邮件客户端 <- POP服务器（返回相关请求数据） 24 | 9. 邮件客户端 -> POP服务器(执行RETR命令:请求返回邮件内容) 25 | 10. 邮件客户端 <- POP服务器（接收邮件） 26 | * 注意：POP3协议未改进前，POP协议接收邮件后则会执行DELE将已接收的邮件标记为将要删除的状态 27 | 11. 邮件客户端 -> POP服务器（执行QUIT命令：请求停止接收邮件） 28 | * 注意：POP3协议未改进前，POP协议QUIT时会将之前用DELE命令标记的邮件删除 29 | 12. 服务端关闭连接 30 | 31 | ![POP3](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/POP3.png?raw=true) 32 | 33 | 34 | * POP3的缺陷 35 | * POP3协议一般会将POP服务器上的已接收邮件删除，尽管目前可以设置不删除，POP服务器上的邮件也仅作为副本。由于这个原因，某些邮件就可能由于保存在不同的主机上而发生丢失 36 | * POP3对浏览器的支持力度不如IMAP 37 | 38 | --- 39 | ## 延伸阅读 40 | 1. [SMTP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000A.md) 41 | 2. [IMAP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000E.md) 42 | 43 | --- 44 | 45 | * 文章更新时间：2016.5.12 46 | * 作者：Seahub 47 | -------------------------------------------------------------------------------- /link/000D.md: -------------------------------------------------------------------------------- 1 | # 浅谈数据层协议--滑动窗口协议 2 | * 阅读难度 低 3 | 4 | ## 前言 5 | 在前面的协议中，数据帧都只是在一个方向上传播，但是，在实际的环境中，往往是需要在两个方向上面传播的。那么我们就来聊一下 6 | 双全工传输的协议 7 | 8 | 在前面的协议，每次传输完一帧，都是要接收方确认的，但是如果，每一条链路由一条前向信道(用于数据)，和一条逆向信道(用于确认)组成，我们可以预见，逆向信道的带宽几乎是被完全浪费了。 9 | 10 | 这个时候我们来想一下，因为数据传输是双向的，机器A向机器B发送数据，然后等待机器B的确认，机器B向机器A发送数据，同样需要机器A发送确认帧，那么，我们想一下，既然B要向A发送数据，还要对之前A发过来的数据进行确认的话，能不能让确认帧搭一下数据帧的"顺风车"呢？事实上我们也是这么实现的。这种暂缓确认以便确认信息被附加到向外发送的数据帧上的技术被称为捎带确认。 11 | 12 | 不过这种技术存在一个问题，暂缓确认来搭数据帧的便车，那要等多久呢，因为你无法预知下一个数据包是什么时候到来，你也没法等待太长的时间，因为这样，发送方会以为发送失败重新发送的。这个时候就要自定义一个时长了，在这个时长内等待，超过这个时长，就单独发送一个确认帧，就好像你有事要回家，你想省点车费买零食所以想搭顺风车，但是等了一段时间还没看到车，毕竟是有事要赶回家，所以只能自己买票回去了 13 | 14 | ## 滑动窗口协议 15 | 在滑动窗口协议中，任何一个出境帧都包含一个序号，范围从0到某个最大值。所有滑动窗口协议的本质都是在任何时刻，发送方总是维持着一组序号，分别对应着允许它发送的帧，我们称这些帧落在发送窗口里面 16 | 17 | 发送方窗口内的序号代表了那些可以被发送的帧，或者那些已经被发送但还没有被确认的帧。任何时候一个新的数据包从网络层到来时，它被赋予窗口中的下一个最高序号，并且窗口的上边界向前移动一格.当收到一个确认时，窗口的下边界也前移一个。按照这种方法发送窗口持续地维持了一系列未被确认的帧,下面是一个大小为1的滑动窗口 18 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/window.png) 19 | 20 | 由于当前在发送方窗口内的帧可能在传输工程中丢失或者损坏，所以，发送方必须在内存中保存这些帧，以便满足可能的重传的需要。 21 | 22 | 因此，如果最大的窗口尺寸为n，则发送方需要n个缓存区来存放未被确认的帧。如果窗口在某个时刻达到了它的最大尺寸，则发送发的数据链路层必须强制关闭网络层，直到有一个缓存区空出来。 23 | 24 | 需要注意一下的是，任何落在窗口外面的帧都会被丢弃，窗口大小为1意味着数据链路层按照正确的顺序接收数据，但是对于大一点的窗口。这个就不成立了。相反，网络层总是按照正确的顺序来接收数据，跟数据链路层的窗口大小没有关系 25 | 26 | ## 结语 27 | 关于数据链路层我们就先了解到这里了，接下来我会和大家一起学习一下更高层次的协议了 28 | 29 | --- 30 | * 文章最近更新时间：2016.5.14 31 | * 作者：Samray 32 | -------------------------------------------------------------------------------- /link/000E.md: -------------------------------------------------------------------------------- 1 | # 应用层之IMAP协议 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 5 | * 上周我们讨论了POP3协议，这周我们聊一下同样是担任“收邮件”工作的IMAP协议。IMAP协议和POP3孰优孰劣，我们在本文后面会有所讨论... 6 | 7 | ## IMAP(Interactive/Internet Mail Access Protocol) - (交互式/互联网)邮件访问协议 8 | * 部分术语解释 9 | * 连接模式：邮件客户端一直监控远程服务器邮件列表状态是否变化（可在邮件客户端设置刷新时间，一般为60s - 180s），若用户通过其他客户端修改邮件列表状态，连接模式下的邮件客户端会将修改数据拉取并合并（这就有点类似于Git的Pull && Merge了） 10 | * 断开模式：邮件客户端不再监控远程服务器邮件列表的变化 11 | 12 | * 一般用户在邮件客户端“收邮件”的流程 13 | 1. 在邮件软件设置IMAP模式、IMAP服务器URL（eg:imap.163.com）以及用户名、密码 14 | 2. 点击收取邮件按钮 15 | 3. 邮件客户端 -> IMAP服务器（进行DNS解析） 16 | 4. 邮件客户端 -> IMAP服务器 143端口(进行TCP连接) 17 | 5. 邮件客户端 <- IMAP服务器（进行认证） 18 | 6. 邮件客户端 -> IMAP服务器(输入用户名、密码) 19 | 7. 邮件客户端 <- IMAP服务器（建立连接模式，传输现在的邮件列表） 20 | 8. 邮件客户端 -> IMAP服务器(用户进行操作，如点进某封邮件，请求服务器数据） 21 | 9. 邮件客户端 <- IMAP服务器(传输用户请求的邮件数据（可能只传部分数据，如附件部分，除非用户点击请求下载，否则不传）) 22 | 10. 邮件客户端 <-> IMAP服务器(在连接模式下，邮件客户端每间隔一段时间自动拉取服务器邮件列表状态并更新) 23 | 11. 邮件客户端 -> IMAP服务器(请求转换至断开模式) 24 | 12. 服务端关闭连接 25 | 26 | ![IMAP](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/imap.png?raw=true) 27 | 28 | 29 | * IMAP的缺陷 30 | * IMAP需要网络环境用于读取邮件，本身不缓存邮件，离线阅读能力较弱 31 | 32 | ## POP3 VS IMAP 33 | 34 | * 比较前言：目前POP3协议以及IMAP协议在很多方面都通过一些扩展的途径来弥补了自身的缺点。比如部分邮件客户端可以在POP3协议工作时不删除服务器邮件，在IMAP协议工作时自动缓存部分邮件。这些扩展很大程度上弥补了POP3与IMAP的缺点，甚至一些能够扩展让他们之间“形同兄弟”。我们下面的优劣比较仅以最原始的POP3协议与IMAP协议进行比较 35 | 36 | --- 37 | 38 | 1. IMAP对浏览器支持更优，虽然说现在大部分浏览器都支持双协议，但是仍然有部分浏览器仅支持/优先支持IMAP协议 39 | 2. IMAP安全性较POP3优。在搭建邮件局域内网时，如果管理员只希望让员工在公司能够访问公司邮件，应该使用IMAP协议。因为IMAP协议需要请求服务器获取数据，当员工在非公司的地方连接网络时，连接的网络非公司内网，不能与公司内网的邮件服务器搭建链接，因此达到了通过内网保护邮件避免外泄的效果 40 | 3. 在早期的IMAP、POP3协议中，POP3协议的用户使用邮件客户端时会自动将邮件数据下载到本地（包括各种超大的附件），而IMAP协议支持部分获取（即用户可以先查看邮件再决定是否下载附件，而非先下载整封邮件内容再决定是否打开附件），但这种情况目前POP3已有改进方案 41 | 4. IMAP协议允许多个用户同时访问邮箱，而POP3协议假定用户是当前邮箱的唯一用户 42 | 5. 使用POP3协议的客户端离线阅读能力较强，IMAP协议较弱。因为IMAP协议每次都要请求服务器获取邮件列表（需要连接网络）。虽然现在大部分邮件客户端在使用IMAP协议时也会自动缓存邮件，但是IMAP离线阅读能力依旧较下载全部邮件副本的POP3协议弱 43 | 44 | ![POP3 VS IMAP](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/popvsimap.png?raw=true) 45 | 46 | --- 47 | 48 | * 我认为，选择POP3还是IMAP需要取决于管理员是想让用户“为了提升离线阅读能力允许离线办公(POP3)”还是,“为了保护数据必须在线办公（IMAP）”。但总体而言，还是IMAP协议更优 49 | 50 | --- 51 | ## 延伸阅读 52 | 1. [SMTP协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000A.md) 53 | 2. [POP3协议](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/link/000C.md) 54 | 55 | --- 56 | 57 | * 文章更新时间：2016.5.18 58 | * 作者：Seahub 59 | -------------------------------------------------------------------------------- /link/000F.md: -------------------------------------------------------------------------------- 1 | # 浅谈数据链路层05之介质访问子层 2 | * 阅读难度 低 3 | 4 | ## 前言 5 | * 网络链路可以分成两大类:使用点到点连接和使用广播信道。我们前面介绍了点到点链路，那么现在我们就来讨论一下广播网络和相应的协议 6 | 7 | *** 8 | 9 | ## 信道分配问题 10 | * 我们先来谈一下静态分配方案 11 | 12 | #### 静态信道分配 13 | * 在多个竞争用户之间分配单个信道的传统做法是把信道容量拆分给多个用户使用。假设有N个用户，则整个宽带被分成N等份，每个用户都有自己专用的频段，所以用户之间不会发生干扰。这似乎很公平嘛，给每个用户平分信道容量，但是，当发送方的数量非常多，且不断变化的时候，或者流量出现突发性的时候，问题就来了。整个频段被分成N份，但是当前之后很少的用户(比N少得多)需要通信，但是流量又很大的时候，却只能拿到平分的容量。又或者是希望通信的用户数超过了N，则有些用户因宽带不够而被拒绝 14 | 15 | * 所以，显而易见，我们需要动态信道分配的方案 16 | 17 | #### 动态信道分配 18 | * 在真正讨论动态信道分配方案的时候，我们有必要来谈一下5个关键假设，所有的方案都是以这几个假设为基础的 19 | 1. 流量独立(independent traffic)。该模型是由N个独立的站点(比如计算机，电话)组成的，每个站点都有一个程序或者用户产生要传输的帧。一旦生成一帧，该站就会被阻塞，直到该帧被成功发出去 20 | 2. 单信道(Single Channel).所有的信道都用这一个信道。所有的站可以在该信道上面传输数据，也可以从该信道接收数据。所有站的能力都相同，尽管站的能力都相同，尽管协议可能为站分配不同的角色(比如优先级) 21 | 3. 冲突可观察(observable Collision)。如果两帧同时传输则它们在时间上就重叠了，由此产生的信号是混乱的。这种情况就叫做冲突。所有的站点都能检测冲突事件的发生。冲突的帧必须以后再次被发送 22 | 4. 时间连续或分槽(Continuous or slotted time)。时间科技假设是连续，即在任何时刻都可以开始传输帧。另外一种选择是把时间分槽或者分成离散的时间间隔(称为时间槽)。帧的传输只能从某个时间槽的起始点开始。一个时间槽分别可能包含01或者多个帧，分别对应于空闲的时间槽，一次发送成功，或者一次冲突 23 | 5.载波侦听或不听(Carrier Sense or no carrier sense)。有了载波侦听的假设，一个站在视图用信道之前就能知道该信道是否被使用。如果信道侦听结果是忙，则每用一个站会再去试图使用该信道。 24 | 25 | *** 26 | ### 多路访问协议 27 | * 那么我们现在就来看一下，动态信道分配的算法 28 | 29 | #### ALOHA 30 | * 我们要在这里讨论两个版本的ALOHA：纯ALOHA和分槽的ALOHA。它们的区别在于时间是连续的，那就是纯粹的ALOHA；或者时间被分成离散槽，所有帧都必须同步到时间槽 31 | 32 | ##### 纯ALOHA 33 | * ALOHA系统的基本思想非常简单:当用户有数据需要发送的时候就发送。当然，这样做是有很大可能产生冲突的，冲突的帧将被破坏。发送方需要某种途径来发现是否发生了冲突。在ALOHA系统中，每个站在给中央计算机发送帧以后，该计算机把该帧重新广播给所有的站。因此，那个发送站通过侦听来自集线器的广播，以此确定是否发送成功。在其他系统中，比如有线局域网中，发送方发送的同时能侦听到冲突的发生 34 | 35 | * 如果帧被损坏了，则发送方要等待一段随机时间，然后再次发送该帧。等待的时间必须是随机的，否则同样的帧会一次又一次地冲突，因为冲突帧被重发的节奏完全一致。如果系统中多个用户共享一个信道的方法出现冲突，则这样的系统称为竞争 36 | 37 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/aloha.png) 38 | 39 | * 无论何时，只要两个帧在相同时间试图占用信道，冲突就会发生(如图)，并且两帧都会被破坏。如果新帧的第一位与几乎快传完的上一帧的最后以为重叠，则两帧都会被彻底破坏(不正确的校验和)，稍后都会被重传。检验和不可能(也不应该)区分出是完全损坏还是局部差错。坏了就是坏了 40 | 41 | * 那么，来谈一下我们最关心的问题，纯ALOHA的效率怎么样呢。经过计算，该系统最好的信道利用率也只有18%.这个真的很难令人满意 42 | 43 | ### 结语 44 | 正是因为纯ALOHA的不尽人意，所以有了分槽ALOHA，更多相关的讨论，我们下次再聊 45 | 46 | --- 47 | * 文章更新时间：2016.5.26 48 | * 作者：Samray 49 | -------------------------------------------------------------------------------- /link/0010.md: -------------------------------------------------------------------------------- 1 | # 应用层之DNS 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 - 为什么要有DNS 5 | * 很久之前，在没有DNS的时代，人们上网都是通过IP地址对网站进行访问。这是一个什么样的概念呢，这就像是我们打电话一样。我们想要访问维基百科，只能通过诸如208.80.154.225之类的IP地址访问，就像我们打电话给一个人，只能通过他的电话号码打过去。但是这样的地址实在不方便书写与记忆，所以人们就发明了DNS，它能够用简单的名称访问网站，而非书写难以记忆以及书写的IP地址。在某种程度上，域名可以理解成我们的短号，以后你再需要打这个人的电话（访问网站）时，只需要输入他容易记忆的短号（域名），而非输入难以记忆的长号（IP地址） 6 | 7 | ## DNS（Domain Name System）- 域名系统 8 | * 部分术语解释 9 | * DNS:一种组织成域层次结构的计算机和网络服务命名系统，用于TCP/IP网咯，将主机名和域名转换成IP地址 10 | * 域命名空间：DNS数据库中的名称形成的一个分层树状结构 11 | * 根域：DNS域名使用时，规定由尾部句号(.)来指定名称位于根或更高级别的层次结构。根域服务器只有13个IP地址，这13个IP地址永远不变，一般写在配置文件中（eg: "."） 12 | * 顶级域：用来指定某个国家/地区/组织使用的类型名称 (eg: .org) 13 | * 第二层域: 个人/组织在Internet上使用的注册名称 (eg: wikipedia.org) 14 | * 子域: 二级域名及二级域名派生的域名 （eg: www.wikipedia.org） 15 | * 主机名: 一般而言，DNS域名最左侧的标签标识网络上特定的主机,如host (eg:host.www.wikipedia.org) 16 | * 就地应答：客户机使用以前查询获得的缓存信息来获取IP地址 17 | * 递归：DNS服务器代表客户机来请求其他DNS服务器，以完全解析该域名，解析后将应答逐层返回(eg: 客户机 -> 本地DNS) 18 | * 迭代：客户机自己使用基于服务器应答的独立和附加查询，尝试联系其他DNS服务器解析域名（eg: DNS服务器 <-> DNS服务器） 19 | * 权威服务器：每个域的域名服务器，直接提供DNS查询服务，不做递归的DNS服务器 20 | * ISP:Internet Service Provider，互联网服务提供商.ISP向广大用户综合提供互联网接入业务的电信运营商 21 | * TTL: Time To Live（生存时间），表示DNS记录在DNS服务器上缓存的时间 22 | 23 | --- 24 | ## A、NS、MX、CNAME记录简介 25 | * A记录: 主机IP地址记录，目标地址只能使用IP地址 26 | * 泛域名解析：将该域名所有未指定的子域名指向一个空间，A记录主机名中填入*，IP地址指向空间IP地址即可 27 | * 负载均衡：需要虚拟主机服务商支持，表示一个子域名有多个目标地址，当用户访问这个域名时，IP地址循环，即将用户的流量分散至不同的主机 28 | * NS记录: 解析服务器记录，表明由哪台服务器对该域名进行解析，NS记录只对子域名生效 29 | * 同样有优先级，数字越小级别越高 30 | * NS记录优先于A记录，如果一个主机地址同时存在NS记录和A记录，则A记录不生效 31 | * MX记录:邮件交换记录，用于将以该域名结尾的电子邮件指向对应的邮件服务器，目标地址可以使用主机名/IP地址 32 | * MX记录可以通过设置优先级实现主辅服务器设置（优先级越小级别越高），也可以使用相同优先级达到负载均衡的目的，同样，负载均衡也要需要邮件服务商支持 33 | * CNAME记录：别名指向记录，为一个主机设置别名，目标主机地址只能使用主机名而非IP地址 34 | * A记录优先于CNAME记录，如果一个主机地址同时存在A记录和CNAME记录，则CNAME记录不生效 35 | 36 | --- 37 | ## DNS工作流程 38 | 1. 客户机 -> 接入互联网 -> ISP分配一个DNS服务器给客户机(客户机亦可手动设置DNS服务器) 39 | 2. 客户机 -> 请求www.wikipedia.org -> 本地DNS 40 | 3. 本地DNS -> 检查缓存是否有地址记录 41 | * 有：返回IP地址，该IP地址被标记为非权威服务器应答 42 | * 无: 下一步 43 | 4. 本地DNS -> 从配置文件获取13个不变的根域名服务器地址 -> 向其中一台发起请求 44 | 5. 根服务器 -> 返回.org的NS记录 -> 返回一系列的主机名和IP 45 | 6. 本地DNS -> 向这一系列的其中一台发起请求 -> .org域服务器 46 | 7. .org域服务器 -> 返回wikipedia.org的NS记录 -> 返回一系列的主机名和IP 47 | 8. 本地DNS -> 向这一系列的其中一台发起请求 -> .wikipedia.org域服务器 48 | 9. .wikipedia.org域服务器 -> 返回www.wikipedia.org的A记录，即返回IP地址 49 | * 此IP地址被标记为权威服务器应答 50 | 10. 本地DNS -> 获取IP地址 -> 保存在缓存中 -> 返回给客户机 51 | 52 | 53 | ![DNS-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/DNS2.png?raw=true) 54 | ![DNS-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/DNS1.png?raw=true) 55 | 56 | ## 续聊 - 权威服务器为什么权威？ 57 | * 由上文我们可以知道，本地DNS一般会缓存许多域名的DNS记录，以加快用户访问的网站速度。我们知道本地DNS主要是ISP DNS服务器。一般ISP DNS服务器更新频率为1 - 2天。这就导致了一个问题出现：别人不用的老域名，我租用了并重新解析到另外一个IP地址，可能需要等很长时间才能正常解析。这是因为在ISP DNS服务器中的数据没有更新导致的。存放在ISP DNS服务器的DNS记录由于没有更新，用户获得的IP地址其实是从ISP DNS服务器缓存中获取的，这就导致了其实获得的IP地址实际上是过期的，我们必须等待下一次ISP DNS服务器缓存更新才能正常的将域名解析到我们的新的IP地址中。而假若我们租用的是一个新域名，解析反而会快一点，这是因为所有的ISP DNS服务器都没有缓存，大家都需要请求权威服务器，查询域名数据库，获得IP地址。而非像前者一样直接从缓存中获取。 58 | * 因此，我认为，权威服务器之所以权威，是因为它保证了域名与IP地址的即时性。只要你问它这个域名代表的IP地址是什么，它告诉你的永远都会是最正确的。相比之下，其他带有缓存的DNS服务器告诉你的，可能已经是“过去式”了。 59 | 60 | --- 61 | ## 参考阅读 62 | 1. [YouTube - DNS Explained](https://www.youtube.com/watch?v=72snZctFFtA) 63 | 2. [王达 - 例解DNS递归/迭代名称解析原理](http://blog.csdn.net/lycb_gz/article/details/11720247) 64 | 65 | --- 66 | * 文章更新时间：2016.5.26 67 | * 作者：Seahub 68 | -------------------------------------------------------------------------------- /link/0011.md: -------------------------------------------------------------------------------- 1 | # 浅谈数据链路层06之多路复用协议 2 | * 阅读难度：中 3 | 4 | ### 前言 5 | * 之前我们提到了多路复用协议，并且举出了第一个协议纯ALOHA,不过这个协议有诸多性能问题，所以现在我们 6 | 一起来了解一起其他的多路访问协议 7 | 8 | ### 分槽ALOHA 9 | * 鉴于纯ALOHA令人抓狂的性能问题，研究人员就推出了一种ALOHA的改进版--分槽ALOHA，顾名思义，分槽就是将时间分成离散的间隔，这种时间间隔就被称作时间槽，然后每个时间槽对应一帧。这种方法要求用户遵守同一的时间槽边界。取得同步时间的一种方法就是由一个特殊的站在每个时间间隔发起一个脉冲信号，就好像时钟整点报时那样 10 | 11 | * 与纯ALOHA不同的是，在分槽ALOHA中，站不允许用户每次敲入回车键就发送帧，相反，它必须等到下一个时间槽的开始时刻，这样，连续的纯ALOHA就变成了离散的ALOHA,这样可以把冲突减少一半 12 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/compare.png) 13 | 14 | * 如图，并且想象现在可能的冲突。在测试帧所在的同一个时间槽中没有其他流量的概率是e^-G(e的负G次方)，G是发送每个包是的尝试次数，于是可以得到 *S=Ge^-G*.分槽ALOHA的尖峰在G=1处，此时吞吐量是S=1/e，大约是0.368，是纯ALOHA的两倍，但是我们也可以看到随着每次发送包时尝试次数的增多，信道性能也随之降低 15 | 16 | ### 载波监听多路协议 17 | * 虽然分槽ALOHA是纯ALOHA性能的两倍，但是它可以达到的最佳利用率也只有1/e。这结果真的很难令人满意。 18 | 所以，我们需要一些更优秀的协议。 19 | * ALOHA性能不佳的很大原因是因为冲突，如果我们可以想办法避免冲突的话，效率会不会提高上去，答案当然是肯定的。那么，如何避免冲突呢，考虑一下，如果别的站在发送信息，我们就先不发送，等到没有站发送的时候 20 | 再去发送，不就可以大大降低冲突的机率了么？这种通过站监听是否存在载波(即是否有传输)，而采取相应的 21 | 行动的协议就被称为载波侦听协议 22 | 23 | #### 1-坚持载波检测多路访问(CSMA) 24 | * 这是我们了解的第一个载波侦听协议,也是最简单的CSMA方案。具体协议是当一个站要发送内容的时候，首先会侦听信道，如果信道空闲，那就发送，如果信道忙，那就等待，一直等待空闲，然后再发送。如果发生冲突那就等待一段随机时间。再重复上面的动作。似乎协议很优秀，但是我们来假设一些情况，假如有三个站，第三个站在发送，然后第一第二个站准备发送，但是它们同时侦听到信道忙碌，它们就很礼貌地等待起来。等第三个站已发送完，因为不知道还有其他的站在侦听准备发送，他们就同时开始发送信息，就造成冲突了。还有一种更微妙的情况，假如站B已经发送了信息，但是信息在信道有一定的延迟，还没到达站A，恰好站A准备发送信息，就侦听信道，因为站B的信息还没到，所以显示是空闲，A就准备发送了，但是这个时候站B的信息刚好到了站A又发送信息了，就会出现冲突了。 25 | 26 | #### 非坚持CSMA 27 | * 在这个协议中，站在发送数据前，也会对信道进行监听，如果空闲的话，就会发送数据，如果信道正在使用的话，它就不会继续监听，它会"走开，去散散步(等待一段随机的时间)"，然后在重复上面的算法。与第一种CSMA 28 | 协议不同之处在于，它不会在信道使用的时候也一直监听着，以便信道空闲就发送数据。所以这就是为什么叫做非坚持CSMA的原因了。相比之下，它更加"谦让有礼" 29 | 30 | #### p-坚持CSMA. 31 | * 当一个站要准备发送数据时，它就侦听信道。如果信道是空闲的话，它就按照概率P发送数据;而以概率Q=1-P 32 | ，将此次发送推迟到下一个时间槽。如果下一个时间槽信道也是空闲，它就按照概率P发送数据，或者按照概率Q 33 | 再次发送数据。这个过程会一直重复，直到帧被发送出去，如果帧还没有发送出去，另外一个站开始发送数据，这个站就好像冲突发生那样，等待一段随机时间，然后继续重复上面的算法.概率P是一个给定值 34 | 35 | #### 总结 36 | * 现在我们就来看一下不同协议的 可计算吞吐量和负载之间的关系(坚持CSMA前面的数值是信道空闲时发送的概率) 37 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/summary.png) 38 | 39 | --- 40 | * 文章编写人: Samray 41 | * 最近更新时间: 2016-6-4 42 | -------------------------------------------------------------------------------- /link/0012.md: -------------------------------------------------------------------------------- 1 | # 应用层之SOAP 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 - Web Service?SOAP? 5 | * Web Service这个词不知道大家有没有听过，其实在2000年左右，这个词是一个十分热门的词。在某种程度上Web Service其实相当于我们现在的“免费短信、免费在线查天气”等网络服务。编程人员对其进行封装和解耦后，放在互联网上供其他编程人员复用。为什么要谈Web Service呢?因为Web Service的实现其实是基于几个协议和一些技术的，如最基本的XML、UUDI、SOAP以及WSDL描述语言。我们知道，HTTP协议是负责传输HTML的，那什么负责传输XML呢？没错，就是SOAP。在某种程度上，SOAP = HTTP + XML。而我们今天要讲的就是这个Web Service的重要组成部分 —— “SOAP” 6 | 7 | ![SOAP-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/SOAP2.jpg?raw=true) 8 | 9 | ## SOAP（Simple Object Access Protocol） 10 | ## 简单对象访问协议 11 | * 部分术语解释 12 | * Web Service定义: Web Service是自适应、自我描述、模块化的应用程序，可以使用标准的互连网协议，将功能体现在互联网和内联网上。这些应用程序可以跨越Web进行发布、定位和调用，可将Web Service视作Web上的组件编程。 13 | * SOAP定义:SOAP是交换数据的一种协议规范，使用在计算机网络Web Service中，交换带结构信息。SOAP简化了Web Server从XML数据库中提取数据时所需的格式化页面的时间。不同应用程序之间按照HTTP通信协议，遵从XML格式执行资料互换，使其抽象于语言实现、平台和硬件。 14 | 15 | 16 | --- 17 | ## SOAP构建语法 18 | ### SOAP构建模块 19 | * SOAP是基于XML的，所以一条SOAP消息实则为一个普通的XML文档，作为一条SOAP消息，可以包含下列元素： 20 | * (必须)Envelope元素: 把XML文档标识为一条SOAP消息 21 | * (必须)Body元素: 包含所有的调用和相应消息 22 | * (可选)Header元素: 包含头部消息(若有必须置于Body前，否则Body最前) 23 | * (可选)Fault元素: 包含错误提示 24 | 25 | ![SOAP-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/SOAP1.png?raw=true) 26 | 27 | ### SOAP语法规则 28 | * SOAP消息必须使用XML编码 29 | * SOAP消息不能包含XML处理指令 30 | * SOAP消息必须使用SOAP Envelope命名空间 31 | * xmlns:soap = "http://www.w3.org/2001/12/soap-envelope" 32 | * SOAP消息必须使用SOAP Encoding命名空间 33 | * soap:encodingStyle = "http://www.w3.org/2001/12/soap-encoding" 34 | * SOAP消息不能包含DTD引用 35 | * DTD: 文档类型定义（Document Type Definition）是一套为了进行程序间数据交换而建立的关于标记符的语法规则 36 | 37 | ### SOAP Envelope（必须） 38 | * xmlns:soap命名空间:必须为"http://www.w3.org/2001/12/soap-envelope" 39 | * xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 40 | * encodingStyle属性:用于定义在文档中使用的数据类型，可以出现在任何SOAP元素中。它将会被应用到元素内容及元素的所有子元素上 41 | * soap:encodingStyle = "URI" 42 | 43 | ### SOAP Header（可选） 44 | * 若SOAP消息中存在Header元素，则必须是Envelope元素的第一个子元素 45 | * actor属性:将Header元素寻址到一个特定的端点 46 | * soap:actor = "URI" 47 | * mustUnderstand属性:用于标识标题项对于接受者而言，是必须的还是可选的 48 | * soap:mustUnderstand = "0" //0 - 可选 | 1 - 必须 49 | * encodingStyle属性:同SOAP Envelope 50 | 51 | ### SOAP Body(必须) 52 | * 请求一部iphone 6s plus 16G手机的价格: 53 | 54 | 55 | 58 | 59 | 60 | 61 | Iphone 6s Plus 16G 62 | 63 | 64 | 65 | 66 | * 响应请求: 67 | 68 | 69 | 72 | 73 | 74 | 75 | 5999 76 | 77 | 78 | 79 | 80 | 81 | ### SOAP Fault元素（可选） 82 | * Fault元素必须是Body元素的子元素，且一条SOAP消息中只能出现一次 83 | * SOAP Fault元素的子元素： 84 | * < faultcode >:错误代码，可含以下值 85 | * VersionMismatch: SOAP Envelope元素命名空间错误/版本号不对 86 | * MustUnderstand: Header带有mustUnderstand设置为"1"的元素无法被解析 87 | * Client: 消息包含错误消息 88 | * Server: 服务器错误 89 | * < faultstring >:错误描述 90 | * < faultactor >:错误原因 91 | * < detail >: 涉及Body元素的应用程序的详细错误信息 92 | 93 | ### SOAP HTTP Binding 94 | * SOAP HTTP Binding是指遵守SOAP协议的HTTP POST/GET，SOAP POST规定至少两个HTTP头：Content-Type与Content-Length 95 | * Content-Type可以为以下两项，MIME类型或XML类型 96 | * Content-Type:MIMEType;charset=character-encoding 97 | * Content-Type:application/soap+xml;charset=utf-8 98 | * Content-Length:请求/响应主体的字节数 99 | 100 | --- 101 | ## SOAP消息基本结构 102 | 103 | 104 | 105 | 108 | 109 | （可选） 110 | ... 111 | ... 112 | 113 | 114 | （必须） 115 | ... 116 | ... 117 | （可选） 118 | ... 119 | ... 120 | 121 | 122 | 123 | 124 | 125 | ## SOAP的优点 126 | * 使用HTTP通信，基于XML，独立于任何平台 127 | * 可绕过企业防火墙 128 | 129 | --- 130 | ## 参考阅读 131 | * [电子商务技术 - Web Service](http://mooc.chaoxing.com/nodedetailcontroller/visitnodedetail?knowledgeId=2628389) 132 | 133 | --- 134 | * 文章更新时间：2016.6.1 135 | * 作者：Seahub 136 | -------------------------------------------------------------------------------- /link/0013.md: -------------------------------------------------------------------------------- 1 | # 浅谈网络层01--认识网络层 2 | * 阅读难度 低 3 | 4 | ## 前言 5 | * 我们之前用了挺长的时间来了解数据链路层了，数据链路层相对还是比较底层，现在我们就来了解一下网络层 6 | 7 | * 根据之前我们提到的网络模型，不同的层次是分别完成不同的功能的，而网络层关注的是如何将源端数据包发送到接收方，那么，还记得数据链路层是干嘛的么？是实现两台相邻机器完整信息块(帧)的有效通信。从帧到数据包，传输的内容的抽象度也越来越高了，也跟网络层次结构的变化相匹配嘛 8 | 9 | ## 相关基础知识 10 | ### 存储转发数据包交换 11 | * 现在让我们来了解一下网络层协议的运行原理，如下图，网络中最主要的组件是网络服务提供商(Internet Service Provider ISP)的设备还有客户端设备。我们不用关心这是一个什么样的网络，是局域网或者是其他？我们只要抓住重点就行了。假如主机H1要发送一个数据包给主机H2，那么它会首先发送数据包给路由器A，然后再由路由器A发送给下一个路由器，就这样循环下去，一直到主机H2接收到数据包，这种就叫做存储-转发数据包交换。你是否疑惑以下路由器A连着有两个路由器(分别是路由器B和路由器C),那路由器A怎么知道要把数据给哪一个路由器呢，是啊，应该给谁呢。恩恩，这个就是网络层关注的一大重点了-路由算法。以后我们会慢慢再了解这个的，现在先提及一下吧 12 | 13 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/envirnment.png) 14 | 15 | ### 关于网络层服务的争论 16 | * 在设计网络层的时候，相关的技术专家就对网络层应该给传输层提供什么样的服务有过激烈的争论，主要争论的就是网络层应该提供面向连接的服务还是无连接的服务。一个阵营(以Internet社区为主)：认为路由器应该做的就只是转发数据包，因为他们觉得无论网络怎么完善，最终还是很难达到真正的可靠，既然是这样，那么差错控制，流量控制这样的事就主机自己做吧。另外一个阵营(代表是电话公司)，他们认为网络提供的服务应该是面向连接的，因为电话系统就是一个很好的例子，如果想实现比较高的服务质量，无连接的服务能提供么？ 17 | 18 | * 其实我觉得这些争论更多是基于自己的位置做出的考虑，都有自己的理由，也很难一下子指出谁好谁不好。那么最终的结果是什么呢?就是我们现在都能看到的，是两种服务都共存了，互相补充了 19 | 20 | #### 无连接服务的实现 21 | * 在无连接服务中，所有的数据包都被独立注入到网络中，并且独立于路由，不需要提前建立任何连接，这样的数据包一般被称为数据报(datagram),类比电报(telegram),对应的网络自然被称作数据报网络了，现在我们就来看一个例子吧 22 | 23 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/datagram.png) 24 | 25 | * 如图，主机H1还是有一个很长的信息要发送给主机H2，由于信息太长了(假设刚好是数据包长度的4倍)，网络层就把信息拆成4个数据包：1，2，3，4，然后发送给路由器A。我们先指出一下，在每个路由器里面都有一个内部表，内部表的作用就是告诉路由器应该把数据包发到哪里去。表项有两个数据:目标地址，和通往目标地址的线路。就拿A的表当例子吧，开始的时候目标是A，因为本身就是路由器A，所以目标的出境线路为空，接下来目标是B，通往目标的出境线路怎么又是B，它的意思是路由器A到路由器B之间有一条直达的线路啦，还不懂，那就看看图吧。C也是同理啦，再到目标地址是D了，那么通往目标地址所使用的出境线路就是B了，就是从B可以到达D，我们看看图就能理解了。接下来的就不用解释啦，不过要说明一点的就是，内部表不是静态的，是会变化的。 26 | 27 | * 图中的数据包1，2，3到达入境线路之后，验证校验和之后，然后被路由器保存起来，然后被分别放到一个新的帧里面，然后转发到路由器C(至于为什么通过C，我们可以先不用考虑)，在被转到E，再给F，然后通过连接到H2的局域网再被发送出去。但是，假如路由器A“发现”ACE线路阻塞了，那怎么办，只有换一条线路咯，所以这次路由器A把数据包转发给了路由器B，接下来，就传递到H2就行了。正如我们上面提到的，这里的重点就是管理路由表，并做出路由选择的路由算法啦 28 | 29 | #### 面向连接服务的实现 30 | * 使用面向连接的服务，在发送数据包之前必需建立一条从源路由器到目标路由器的路径，这种连接被称为虚电路，就是类似于电话系统的线路咯虚电路的工作原理呢，就是避免像无连接那样，每次发送数据包都要确定一条发送的路径，正好相反，虚电路的目标就是一开始就把一条从原机器到目标机器的路径确定下来，然后保存在路由表里面，每次发送就按着这条路径就行啦，然后确定不再发送数据的时候，就断开连接(是不是很像打完电话，挂电话呢),现在我们也来看一个例子吧 31 | 32 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/vc.png) 33 | 34 | * 主机H1已经建立了一条与主机H2的虚电路连接1，连接记录被保存在每个路由表项中。A路由表中的第一行说明标识1的标示符是来自主机H1，然后发送给C，标示符1也传递给了C了，就这样路由下去，直到到达H2.假设现在H3也要发送数据给H2，那么它选择连接标示符1(因为这是它唯一的连接，所以它选择了1)，然后告诉网络要建立虚电路，因此每个路由表增加一个表项，但是这样，H1的连接标示符是1，H3的连接标示符也是1，路由器A是源路由器，它知道哪个1是来自哪个路由器，但是接下来靠标示符分辨数据包来源的路由器就分不清了，所以为了解决这个问题，路由器A在数据包出境的时候，给H3的数据包传递一个不一样的标示符2，那么问题不就解决了么。这个交换标示符的过程就被称作标签交换了。以后有机会，我们会了解它的更多细节 35 | 36 | ### 虚电路和数据报网络的比较 37 | * 我们先来看一虚电路和数据报的比较 38 | 39 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/comparility.png) 40 | 41 | * 正如我们上面提到的那样，从设计开始，面向连接和无连接的服务就争论不停，两种技术都有很明显的优缺点。面向连接的服务建立虚电路以后，传输数据的过程就有保证了，但是建立虚电路这个过程本身就要耗费资源和时间，而面向连接的数据报技术，只要发数据报就能发送了(只是相比虚电路，忽略其他细节)，但是它本身每次又要花费时间资源实现路由算法。另一个方面，虚电路是有利于实现保证服务质量和避免网络阻塞，这个对于数据报就有点"强人所难了"，但是虚电路本身也不是绝对稳定(也没有可能绝对稳定)，如果虚电路的路径上的一个路由器崩溃了，内存的数据全没了，然后重启了。虚电路就整条失效，那么，就只能重新建立一条新的虚电路。但是对于数据报来说，其中一个路由器挂了，只是在该路由器的数据丢了而已，数据报还是可以很好运行的，下次发送数据的时候绕过这个崩溃的路由器就好了。其实，我觉得单纯地去争论哪一种技术更好是没有意思的，两种技术都有相当明显的优缺点。我还是觉得，没有适用所有问题的最优解决方案，只有针对特定问题的最优解决方案。 42 | 43 | --- 44 | * 文章编写人: Samray 45 | * 最近更新时间: 2016-6-20 46 | 47 | 48 | -------------------------------------------------------------------------------- /link/0014.md: -------------------------------------------------------------------------------- 1 | # 应用层之FTP 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 - 有HTTP为什么还需要FTP？ 5 | * 众所周知，HTTP可以在网络上传输各种各样的信息，这其中当然也包含一些文件信息。那么，既然HTTP已经这么强大了，我们还需要所谓的"FTP"吗？答案当然是需要的。通过FTP传输文件要比其他协议更加有效，主要原因有两个方面。其一：FTP只用于正确地传送文件，不会像HTTP那样翻译文件的内容。其二：一般而言，使用FTP进行通信的服务器一般是一台独立的FTP服务器。所以，FTP服务器会将他自己的所有资源都投入到处理FTP事务中。简而言之，“专注”让FTP更加高效，更加适合用于文件传输。 6 | * 当然，现在因为有更优的协议出现，同时HTTP协议也可以在某些程度上进行文件处理，且HTTP相对不会使用FTP的用户而言，更加方便下载，所以FTP出现的频率也就大幅减少了。 7 | 8 | ![FTP-3](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/FTP3.jpg?raw=true) 9 | 10 | 11 | ## 文件传输协议 FTP（File Protocol Protocol） 12 | * 部分术语解释 13 | * FTP服务端端口21：标准命令TCP端口号，服务端控制端口，负责传输控制流 14 | * FTP服务端端口20：服务端数据端口，负责传输数据流 15 | * 高端端口:端口号大于1024 16 | 17 | ![FTP-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/FTP2.png?raw=true) 18 | 19 | --- 20 | ## FTP两种传输方式 21 | * ASCII传输模式 22 | * 定义:假定用户正在处理的文件包含简单的ASCII码文本，进行拷贝处理。如果用户机器上运行的编码并非ASCII，则当文件传输时，FTP通常会自动地调整文件内容，以便于把文件解释成用户计算机存储文本文件的格式 23 | * 可能出现的情况：上面提到，FTP有可能把文件内容转化成特定的文本文件格式。但是，万一我们处理的不是文本文件，而是程序呢?事实上，在处理任何非文本文件之前，我们需要用Binary命令告诉FTP逐字拷贝（即采用二进制传输模式），而非对这些文件运用ASCII传输模式。 24 | * 二进制传输模式 25 | * 定义:逐字拷贝，即在二进制传输中，保持文件的位序，以便原始位和拷贝的是逐位一一对应的。 26 | 27 | --- 28 | ## FTP两种运行模式 29 | ### FTP主动模式（Standard/PORT） 30 | * 主动模式：客户端和服务端同时打开并监听一个端口以创建连接。 31 | * 步骤(两次TCP)： 32 | 1. 客户端端口A和FTP服务端的21端口建立TCP连接 33 | 2. 客户端端口A向FTP服务端的21端口发送PORT命令（PORT命令包括客户端用来接收数据的端口B） 34 | 3. FTP服务端收到命令后，打开FTP服务端的20号数据端口，与客户端端口B建立TCP连接 35 | 4. FTP通过这个客户端端口B进行数据传输, 在此例子中 36 | * 客户端端口A:本地控制端口，负责传输控制流 37 | * 客户端端口B:本地数据端口，负责传输数据流 38 | 39 | ### FTP被动模式 （Passive/Pasv） 40 | * 被动模式：只要求服务端产生一个监听相应端口的进程 41 | * 步骤(两次TCP)： 42 | 1. 客户端端口A和FTP服务端的21端口建立TCP连接 43 | 2. 客户端端口A向FTP服务端的21端口发送Pasv命令） 44 | 3. FTP服务端收到命令后，随机打开一个高端端口C，告知客户端在此端口上传输数据 45 | 4. FTP服务端与连接至服务端高端端口，通过这个端口进行数据传输(一次TCP连接) 46 | 47 | ![FTP-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/FTP1.gif?raw=true) 48 | --- 49 | ## 匿名FTP 50 | * 因为使用FTP时，必须登录。因此，出现了一种机制——匿名FTP，它可以让用户无需密码就可以连接到FTP服务器，并获得下载权限。 51 | * 一般匿名FTP有如下特征，具体需要看系统管理员的设置 52 | * FTP用户登录名为anonymous 53 | * FTP登录密码可为任意字符串，但习惯上，用户会使用自己的E-mail地址作为密码，以方便系统管理员记录下来，谁试用了匿名账户下载了这些文件 54 | * 一般匿名账户仅提供下载权限，不提供上传权限 55 | * 匿名账户可能只能看到部分向公众开放的目录，其余目录则处于隐藏状态 56 | * 匿名FTP只适用于提供了这项服务的主机 57 | 58 | --- 59 | ## FTP账户分类 60 | * Real账户:权限最大的账户，当这类账户登录到FTP服务端时，其默认的主目录为账户名称命名的目录。同时，这类账户也可以切换到其他目录中（包括系统的主目录）。 61 | * Guest账户:只当这类账户登录到FTP服务端时，其默认的主目录为账户名称命名的目录。但这类用户不能切换到其他账户，只能访问自己的主目录。 62 | * Anonymous账户:没有指定账户，但它仍然可以进行匿名访问某些公开的资源。 63 | 64 | --- 65 | ## FTP断点下载与续传 66 | ### 断点下载 67 | 1. 客户端向服务端发送“Rest + 本地文件长度”命令，告诉服务端，客户端要断点下载了。 68 | * 这一步，服务端会返回是否支持断点续传 69 | * 若支持，服务端返回成功代码，需要知道断点续传哪一个文件 70 | 2. 客户端向服务端发送“Retr + 文件名”命令，告诉服务端具体要断点下载哪个文件 71 | * 服务端根据客户端的信息，开始服务端定位文件指针，并根据客户端发送的本地文件长度推出服务端要发送的文件长度 72 | * 同时，客户端开始定位本地文件末尾 73 | 3. 当两端都做好准备工作后，客户端创建Socket，以主动/被动运行模式建立数据通道，循环调用Recv命令从远程服务端接受数据并追加入本地文件 74 | 75 | ### 断点上传 76 | 1. 客户端获取服务端上和本地要上传文件的同名文件大小 77 | 2. 客户端向服务端发送“Appe ＋文件名”，通知服务端，接下来传输的数据，要附加到这个文件末尾。 78 | 3. 客户端/服务端分别定位本地/远程文件指针 79 | 4. 从本地文件指针处读数据并写至远程文件指针处 80 | 81 | --- 82 | ## FTP常用提示处理代码 83 | * 提示处理代码定义方面与HTTP协议类似，主要为： 84 | * 2XX: 成功 85 | * 3XX: 权限问题 86 | * 4XX: 文件问题 87 | * 5xx: 服务器问题 88 | * 常用提示处理代码 89 | * 220:命令执行正常结束 90 | * 227:进入被动模式 91 | * 530:密码错误 92 | * 550:目录/文件已经被删除 93 | * 552:对请求文件的操作中止，因超出存储分配 94 | 95 | --- 96 | ## FTP的缺点 97 | 1. 密码和文件内容都使用明文传输，没有加密，因此容易被窃听 98 | 2. FTP在需要传输文件数量很多的小文件时，性能不好 99 | 3. 当数据通过数据流传输时，控制流处于空闲状态，而当控制流空闲很长时间后，客户端的防火墙会将会话判为超时。即在大文件传输时，传输时间超过一定阈值后，控制会话会被防火墙断开，导致传输会产生一些错误。 100 | 4. 当同时传输多个文件时，因多次握手，导致最终性能不如HTTP 101 | 102 | --- 103 | ## 参考阅读 104 | * [FTP命令详解](http://cs.ecust.edu.cn/snwei/studypc/oftencommand/ftp.htm) 105 | * [FTP协议和HTTP协议的12点比较(文件上传/下载)](https://www.oschina.net/news/28162/http-vs-ftp) 106 | * [Youtube - What`s FTP](https://www.youtube.com/watch?v=8IC8-WIkE2c) 107 | 108 | --- 109 | * 文章更新时间：2016.6.15 110 | * 作者：Seahub 111 | -------------------------------------------------------------------------------- /link/0015.md: -------------------------------------------------------------------------------- 1 | # 浅谈网络层02之路由算法 2 | * 阅读难度 低 3 | 4 | ## 前言 5 | * 记得我们之前曾经多次提到路由算法，现在我们就来了解一下各种的路由算法，因为路由算法很多，所以我决定分两篇博文来了解。网络层的主要功能是把数据包从机器路由到目标机器，如何选择路由的算法以及这些算法所用到的数据结构是网络层的最主要内容 6 | 7 | ### 相关知识 8 | #### 转发与路由 9 | * 我们先来区分一下转发和路由吧，路由呢，是决定使用哪一条路径，转发呢，是在一个数据包到达的时采取什么动作。可以想象成路由器里有两个进程，一个进程负责把数据包沿着给定的路径进行发送。那么，路径，谁来指定呢，这个时候，另外一个进程就负责路由的生成和更新了。 10 | 11 | #### 路由的类型 12 | * 路由算法的类型分为两种，自适应和非自适应算法。顾名思义，差别就是会不会自动适应，适应什么呢，就是根据当前流量，拥塞情况等更新路由表。非自适应算法是预先离线计算好的，然后下载到路由器的;而自适应算法则会改变它们的路由策略以便反映网络拓扑结构的变化，通常是网络流量的变化 13 | 14 | #### 最短路径算法 15 | * 又来顾名思义啦，最短路径算法，就是找出两个路由器之间的最短路径的算法(有点废话的感觉),我们来想一下，我们应该用什么度量来标示路径的长短呢，有很多种类型的,包括，跳数，物理距离，路由器之间的平均延迟等等. 16 | * 现在我们先来讨论一下物理距离的情况，下图是一些路由器和路径，数字代表权值，我们可以理解成物理距离 17 | 18 | ![routing](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/routing.png) 19 | 20 | * 我们先来了解一下算法吧，这算法在离散数学里面被重点提到过了，这种算法可以找到一个源节点到所有目标节点的的最短路径，每一个节点都标出了(在括号里面标出)从源节点沿着已经的最佳路径到达本节点的距离。初始时，所有的节点都不知道，因此所有的节点都被标为无限远。随着算法的不断进行，一些节点被陆续找到，于是节点可能发生了变化，以便反映出更好的路径。每个标识有可能是暂时的，也有可能是永久的，初始的时候，所有的标识都是暂时的。当发现一个标记从源节点到该节点的最短可能路径，该标记就变成永久的，以后不会改变 21 | 22 | * 是不是觉得这个对算法的定义很抽象（我不会告诉你，离散上面的写得更抽象).我们还是对着图来好好分析一下吧，我们要找到从A到D的最短路径最开始，标记A为起点，然后所有的路径都是未知的，所以都标注为无限大，然后将A标为永久（永久用实心圆来标志），A有两条路径，到B和到D，发现B更短(2)，所以选择了B，这个时候将B标示为暂时的，然后沿着B节点，也有两个节点，C和E，发现E更短，就把E标示为暂时的，这个时候，因为从A到E，不存在比ABE更短的路径，（我们也可以通过反证法，如果存在更短的路径，就不会经过B再到达E），所以这个时候将B标示为永久。然后在E点有两条路径，到达GF，因为到达G的路径长度(1)加上E本来的标识(4)小于节点原来的标记(6)，说明我们找到一个更短的节点，所以我们把E标识为永久，把G标示为暂时，然后因为G到达H的总路径长度是9，大于E到F的路径长度，所以节点回退到E，走向了F路径，然后F可以到CH，因为到达H的总路径(8)小于原来的路径总长度(9)，所以找到一条新的最短路径把F标示为永久，把H标示为暂时，最后到达我就不描述了。这个就是算法的大概实现过程了 23 | 24 | #### 泛洪算法 25 | * 泛洪算法实现的核心就是将每一个入境的数据包发送到除了该数据包到达的那条线路以外的所有线路(是不是很像洪水过境)。这种技术很显言会产生很多的重复数据包，我们应该采取一些办法来抑制泛洪算法产生无限多的数据包，一种做法就是添加一个计数器，每一跳就减1计数器为0，就丢弃该数据包。通常，初始的时候，计数器的初始值应该是源路由器到目标路由器的距离，最坏情况下应该是网络的直径。还有一种实现方法就是在数据包里面加一个序号，路由器有一张表记录发过的数据的序号，每次发送之前先检查一下表，如果发现已经发送过了，就丢弃该数据包。泛洪算法也是一种路由算法，只不过有点不切实际，不用如果用来进行广播，效果还是很好的。 26 | 27 | ## 结语 28 | * 我们现在就只了解了两种比较简单的算法，还有其他的路由算法，我们接下来再继续了解 29 | 30 | --- 31 | * 文章编写人: Samray 32 | * 最近更新时间: 2016-6-20 33 | -------------------------------------------------------------------------------- /link/0016.md: -------------------------------------------------------------------------------- 1 | # 应用层之Telent 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 - 远程控制底层到底是怎样实现的？ 5 | * 相信读者们肯定用过很多远程控制软件，诸如TeamViewer等。但是，我们有没有认真的想过他们的底层是通过怎么样的方式进行通信的呢?本节我会向大家介绍用于实现终端上的远程控制的协议——Telent协议，希望大家有所启发。 6 | 7 | ## Telnet协议 8 | * 部分术语解释 9 | * NVT:Net Virtual Terminal，由Telnet协议定义的，一种数据和命令在Internet上的传输方式 10 | * 对于发送的数据：客户端把本地的终端控键转换为NVT格式，发送到服务器。服务端将收到的NVT格式数据，从NVT格式转换为服务端系统需要的数据和命令格式 11 | * 对于返回的数据：服务端将服务端处的数据和命令转换为NVT格式。客户端将接收到的NVT格式数据再转换为本地的格式 12 | * NVTASCII:代表7比特的ASCII字符集，网间网协议族都使用NVTASCII。每个7比特的字符都以8比特格式发送，最高位比特为0，并且行结束符以/r/n来表示,单独的回车以/r/0表示 13 | * IAC:Interpret As Command，当客户端/服务端发送的命令并非数据流而是命令序列时，它就在数据流中插入一个特殊的保留字符，这个特殊字符便是IAC。当接收方在一个数据流中发现IAC字符时，它就把后继的字节处理成一个命令序列 14 | 15 | --- 16 | ## Telent协议的特点 17 | * 适应异构:为适应多个操作系统，使用NVT格式进行传输 18 | * 传输远地命令:将正常的ASCII字符与控制命令区分，并以NVT格式传输 19 | * 这种区分使得Telent协议具有更大的灵活性，以及使得客户端可以正确地输入指令/使用快捷键，而不会使得快捷键的控制功能与普通的输入字符混淆 20 | * 数据流向:每一次的输入输出，因为需要经过NVT格式转换，所以客户端都需要将进程环境切换好几次(客户端输入，客户端打包NVT,客户端发送，服务端接收，服务端解包NVT，返回服务端终端)，因此若Telent协议设计为应用软件，则会导致效率不高的问题出现 21 | * 强制命令:强制指令是指，当客户端误向服务端发送错误的指令导致死循环后，Telent协议可使用紧急指令（由Telent的数据标记字节 + TCP设置并发送紧急数据的报文段通知服务端），强制服务端抛弃无用数据，以让服务端恢复正常，而非让无用数据把TCP连接的缓冲区挤满导致客户端“掉线”。 22 | * 选项协商:为了Telent协议的适应异构性，我们必须把客户端和服务端的"冲突选项"去掉。通信的任何一端都可以发出协商选项的申请，任何一端都可以接受或拒绝这个申请。 23 | * eg:我客户端上面有一个选项A，你服务端上面有一个选项B，刚好这两个选项是冲突的，因此，我们必须先坐下来协商怎么弄，是用你的还是用我的，还是大家都不用。 24 | 25 | ![telent-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/telent1.gif?raw=true) 26 | 27 | --- 28 | ## 使用Telent协议进行远程控制的条件 29 | * 在客户机中装有包含Telent协议的客户端 30 | * 知道服务器的IP地址/域名 31 | * 知道服务器的用户名 && 密码 32 | 33 | --- 34 | ## Telent协议工作流程 35 | * 客户端与服务端建立TCP连接 36 | * 客户端向服务端发送一个IP包 37 | * 该IP包包含以NVT格式封装的用户名及密码，用于验证用户 38 | * 客户端与服务端开始传输数据。传输的数据主要为由客户端以NVT格式封装的NVTASCII与控制指令，以及由服务端以NVT格式封装的命令回显与命令执行结果 39 | * 传输完成后，客户端对服务端提出，关闭TCP连接，连接中止 40 | 41 | ![telent-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/telent2.jpg?raw=true) 42 | 43 | --- 44 | ## Telent的缺点 45 | * Telent传输的数据没有加密，可能导致账号、密码等数据被窃听，因此相对于Telent，很多服务器会选择更安全的SSH 46 | 47 | --- 48 | ## 参考阅读 49 | * [Telent协议详解](http://www.cnblogs.com/dazhaxie/archive/2012/06/27/2566054.html) 50 | * [Youtube - telnet協議](https://www.youtube.com/watch?v=SR1yM3IkrfI) 51 | 52 | --- 53 | * 文章更新时间：2016.6.16 54 | * 作者：Seahub 55 | -------------------------------------------------------------------------------- /link/0017.md: -------------------------------------------------------------------------------- 1 | # 浅谈网络层03之路由算法 2 | * 阅读难度 低 3 | 4 | ### 前言 5 | 之前我们就有提到过自适应路由算法（即动态路由算法），那么现在我们就来聊一下相关的动态路由算法 6 | 7 | ### 距离矢量算法 8 | * 矢量距离算法的工作原理是：每个路由器维护一张表(即一个矢量)，表中列出了当前已知的到每个目标的最佳距离，以及所使用的链路。这些表通过邻居之间相互交换信息而不断被更新，每个路由器都了解每个到达每个目的地的最佳链路 9 | 10 | * 在距离矢量路由算法中，每个路由器维护一张路由表，它以网络每个路由器为索引，并且每个路由器对应一个表项。该表项包含两个部分：到达该目标路由器的首选出境线路，以及到达该目标的距离估计值，距离的度量不是绝对的，正如我们前面提到的那样，度量可以是很多中因素。 11 | 12 | * 假定路由器知道他到每一个邻居的距离。如果所用的度量是跳数，那么距离就是一跳(因为是邻居嘛)。如果度量值为传播延迟，则路由器很容易测量出链路的传播延迟。他只要直接发送一个特殊的echo数据(回显数据)，邻居收到后盖上时间戳，尽可能快地发回来就可以知道延迟了。 13 | 14 | * 现在就让我们来看一下 15 | 16 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/dvr.png) 17 | 18 | * 如图，左图显示了一个网络，右图显示的是A I H K 四个路由器到其他路由器的延迟时间，例如I声称到A的延迟是24ms ，到B是36ms的延迟...然后知道J已经测量和估计了它到零件A I H K的延迟分别是8 10 12 6(看最右边更新的表项).现在要找出一条到G的最短路径，已知J到A延迟是8ms，A声称它到G延迟是18，所以J经过A到G的延迟是26，同理可得JIG=41(31+10) JHG=18(6+12) JKG=37(31+6).所以，很容易就可以看出，最佳的路径是JHG 19 | 20 | #### 问题 21 | * 整个网络最佳路径的寻求过程称为收敛。距离矢量路由算法作为一项简单技术很有用，因为路由器可以在所有的路径中选择出一条最短路径。但实际上它存在着一个非常严重的问题，它对于正确的信息反应很迅速，但是对于不正确的信息就反应很缓慢，似乎很抽象，现在我们就来聊一聊是什么回事。 22 | 23 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/cti.png) 24 | 25 | * 如图，路由器B C D E 到A 的距离分别是1 2 3 4。突然间A B之间的链路断开连接了，所以在第一次信息交换是，B没有听到来自A的任何信息，幸运的是，C说“不用担心，我有一条通向A的长度为2的路径”。B并不怀疑,然后B就认为他可以通过C到达A，路径长度为3(似乎出现了问题),在第一次交换以后，D和E并不更新它们的A表项，第二次交换的时候，C注意到了，他有两个邻居声称了一条延迟为3的到达A的路径，它随机挑选一条，并把自己到A的距离更新为4，这个时候，我们应该发现出现了问题了，逐渐地，所有的路由器都会趋向无穷大，但是所需的交换的次数依赖于代表无穷大的数值。所以，明智的做法是把无穷大设置为最长的路径加一 26 | 27 | ### 链路状态路由 28 | * 因为矢量路由算法存在的收敛问题，所以需要有更好的算法来取代它，它就是链路状态路由算法链路状态算法的设计思想很简单，可以用五个部分来描述，这五个部分是缺一不可的，分别是 29 | * 发现它的邻居节点，并了解其网络地址 30 | * 设置到每个邻居节点的距离或者成本度量值 31 | * 构造一个包含所有刚获得的链路信息包 32 | * 将这个发送给所有其他的路由器，并接收来自所有其它路由器的信息包 33 | * 计算出到每个其他路由器的最短路径 34 | 35 | #### 发现邻居 36 | * 它只需要在每一条的点到点线路上发送一个特殊的HELLO数据包。线路的另一端的路由器应该返回一个应答说明自己是谁，说明自己声明的名字(或者称为标示)，必须是唯一的 37 | 38 | #### 设置链路成本 39 | * 为了寻找最短路径，链路状态路由算法需要每条链路以距离或成本度量，举例以成本度量,一种选择就是成本与链路带宽成反比，例如1Gbps的以太网成本是1，而100mbps的成本可能是10.这样就可以使得高容量额的路径成为路由更好的选择 40 | 41 | #### 构造链路延迟状态包 42 | * 该数据包的内容首先是发送方的标示符(上面提到的名字)，接着是一个序号和年龄，还有一个邻居列表，对于每个邻居，还有到这个邻居延迟，接下来我们会详细分析一下数据包的 43 | 44 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/con.png) 45 | 46 | #### 分发链路状态包 47 | * 还记得上面我们的描述么，将数据包发送给所有的其他的路由器，怎么发送到所有的路由器的，还记得我们之前提到过的泛洪算法么，现在就是它的用武之地了，用来发送数据包给所有的路由器。不过在分发数据包的过程，我们还有一些问题要解决一下: 48 | * 发送的数据包包括了序号，如果序号绕回，就可能产生混淆了，所以使用32位的序号是一个较好的解决方法，因为即使是一秒发送一个数据包，也要137年才能绕回 49 | * 如果一个路由器崩溃了，那么保存的序号记录就会全部丢失，如果再从0开始，那么下一个数据包将被作为重复数据包被拒绝，那么应该怎么办呢 50 | 51 | * 还记得上面提到的那个年龄的字段么，它就是用来解决这些问题的，每个数据包包含一个年龄的字段，然后每秒钟将年龄减1.当年龄值减为0时，就丢弃该数据包。所以这在泛洪算法中，数据包就不会永远生存下去了 52 | 53 | * 这个算法的改进使算法更加健壮了。当一个链路状态数据被泛洪到一个路由器时，它没有立即被排入队列等待运输，相反，它首先被放到一个保留区中等待一段时间。如果在这个数据包转发出去之前有新的数据包到来，那么就比较他们的序号。序号相等的话，就丢掉一个重复的数据包，如果不等的话，就丢掉老的数据包。为了防止线路产生错误导致丢包和错包，所有的链路状态数据包都要被确认 54 | 55 | ### 结语 56 | * 链路状态算法相比矢量路由算法，它因为没有无穷计数产生的慢收敛问题，所以工作得更好，但是因为它的缓冲区等要求，就需要更多的内存和计算。 57 | * 作了简单的了解之后，我们下次再去其他有关路由算法的东西。因为网络层一大核心就是路由算法，所以我们还是要多多关注 58 | 59 | --- 60 | * 文章编写人: Samray 61 | * 最近更新时间: 2016-6-20 62 | -------------------------------------------------------------------------------- /link/0018.md: -------------------------------------------------------------------------------- 1 | # 应用层之XMPP(Jabber) 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 - XMPP的历史 5 | * 在20年之前（1996年），一家在我看来，具有跨时代意义的公司——ICQ诞生了，它可以使人和人之间在互联网快速直接交流。也许今天在我们看来，很普通，无非就是一个QQ、一个WhatsApp,一个WeChat而已。但1996年是一个什么样的状态呢，这样说吧，我们大家熟悉的Xp是2001年发布的。2000年9月微软才发布了windows ME（最后一款基于DOS内核的windows系统）。简而言之，在那个时代，ICQ的带给大家的即时通信能力，是很令人惊讶的。 6 | 7 | * 于是，很多类ICQ的软件出现了，比如Yahoo! Pager。于是乎，一个问题又出现了，用户a用平台A，用户b用平台B，数据不互通导致大家必须使用同一款软件进行即时通信。在那个即时通信刚刚兴起，即时通信软件五花八门的年代，这个其实是很不方面的（不像现在基本上两三家垄断全球）。简单来说，10个人里面，10个人都用着不同的即时通信软件。 8 | 9 | * 程序员从来都是改变世界的人，所以他们企图“互通”这些即时通信软件的数据，目的是想要让大家可以使用不同的即时通信软件进行通信。结果当然是失败的。失败的原因主要是因为，在那个年代，商业公司的通信协议都是使用自己研究的、闭源的协议。你不知道每家公司的内部闭源协议，当然也就没有办法实现“互通”了。 10 | 11 | * 但是，这促进了一个新的协议产生 —— XMPP。他是一个基于XML的即时通信协议。主要目的就是为了“去中心化”。简单来说，就是为各种“闭源”协议提供了一个接口，只要其他协议去实现了这个接口，遵循了XMPP的规范，其他遵循XMPP规范的协议就可以与这个协议进行互联，即数据传输。 12 | 13 | --- 14 | 15 | ## 可扩展通讯和表示协议 - XMPP（Extensible Messaging and Presence Protocol，前称Jabber） 16 | * XMPP定义：XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性，XMPP是可扩展的，可以通过发送扩展的信息来处理用户的需求。XMPP基本的网络形式是通过TCP/IP连接到服务器，然后传输XML。XMPP与IMPP、PRIM、SIP（SIMPLE）合称四大IM协议，而在此4大协议中，XMPP是最为灵活的。 17 | ![XMPP-1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/XMPP1.gif?raw=true) 18 | 19 | --- 20 | ## XMPP的三个角色 21 | * XMPP中存在三个角色：客户端，网关，服务器，通信能够在这三者的任意两个之间双向发生。 22 | 23 | ### 客户端 24 | * XMPP客户端需要与服务端通过XML在TCP Socket 5222端口进行通信，而不需要客户端之间直接进行通信。 25 | 基本的XMPP客户端必须实现以下标准协议（XEP-0211）： 26 | * XEP-0030 服务发现 Service Discovery 27 | * XEP-0115 实体能力 Entity Capabilities 28 | * RFC3920 核心协议 Core 29 | * RFC3921 即时通讯和表示协议 Instant Messaging and Presence 30 | 31 | * XMPP客户端是较为容易实现的，XMPP对它有以下限制： 32 | * 通过TCP Socket与XMPP Server进行通信 33 | * 能够理解消息数据类型、解析XML信息包 34 | 35 | * 之所以XMPP对客户端的要求如此简单，是因为XMPP把重点的核心部分放到了服务端处理，目的是使客户端更加易于编写，客户端更新更加容易。 36 | 37 | ### 网关 38 | * 其实大家看了“聊一聊”之后，应该知道XMPP最强大的特点就是：可以和其他即时通信系统交换信息。但是协议不同，怎么样交换信息呢？其实，XMPP是通过协议转换来实现的。目前有几种主流即时通信协议都没有公开，所以XMPP服务器本身并没有实现和其他协议的转换，但它的架构允许转换的实现。 39 | 40 | * XMPP网关:实现这个特殊功能的服务端在XMPP架构里叫做网关。这个特殊的网关能够使得XMPP在某种程度上，“兼容”所有其他即时通信协议，XMPP的灵活性也因为"网关的存在"而更加强大。 41 | 42 | * 怎样理解这个网关呢?其实我们可以把XMPP理解成我们的万能插座，他提供了一个"插口"给我们，我们无能是A型插头还是B型、C型、D型等等所有型号的插头都可以插进去。而这个插口，在编程上，其实是一个接口。XMPP网关其实又可以理解为XMPP向外暴露的一个可以兼容其他主流即时通讯协议的一个接口。因此，我们通过这个接口，可以实现不同协议之间的通信转换，就如同使用不同的插座一般灵活。 43 | 44 | ### 服务器 45 | * 在XMPP中，服务器和网关一样，十分重要。XMPP服务器主要遵循两个原则： 46 | * 监听客户端连接，并直接与客户端应用程序通信 47 | * 服务器与其他XMPP服务器通信； 48 | 49 | * 基本的XMPP服务器必须实现以下标准协议 50 | * XEP-0030 服务发现 Service Discovery 51 | * RFC3920 核心协议 Core 52 | * RFC3921 即时通讯和表示 Instant Messaging and Presence 53 | 54 | * 目前，XMPP开源服务器包含一般以下模块 55 | * Session管理 56 | * 用户和服务器之间的通信 57 | * 服务器之间的通信 58 | * DNS转换 59 | * 用户注册与用户登录 60 | * 存储用户的个人信息和朋友名单 61 | * 保留用户在下线时收到的信息 62 | * 用户的身份验证和权限的验证 63 | * 根据用户的要求过滤信息 64 | * 记录日志 65 | * 其他扩展服务 66 | 67 | --- 68 | ## XMPP协议工作流程(本部分内容来自维基百科) 69 | * 假设朱丽叶（juliet@capulet.com）想和罗密欧（romeo@montague.net）通话，他们两人的账号分别在Capulet.com及Montague.net的服务器上。当朱丽叶输入消息并按下发送钮之后，一连串的事件就发生了： 70 | 1. 朱丽叶的XMPP客户端将她的消息发送到Capulet.com XMPP服务器。 71 | 2. Capulet.com XMPP服务器打开与Montague.net XMPP服务器的连接。 72 | 3. Montague.net XMPP服务器将消息寄送给罗密欧。如果他目前不在在线，那么存储消息以待稍后寄送。 73 | 4. 罗密欧与朱丽叶两人的XMPP服务是由两家不同的业者所提供的，而他们彼此传讯时，不须拥有对方服务器的账号，也不须成为对方业者的会员。 74 | 75 | ![XMPP-2-5](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/XMPP2-5.png?raw=true) 76 | 77 | 78 | ![XMPP-2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/XMPP2.png?raw=true) 79 | 80 | --- 81 | ## XMPP的优缺点 82 | ### 优点 83 | 1. 分布式：XMPP没有中央主服务器，任何人都可以运行自己的XMPP服务器。由于没有中央主服务器，纵然是功能再强大的GFW也没有办法"和谐"它 84 | 2. 安全：XMPP默认使用SASL及TLS等技术的可靠安全性(XMPP–>SASL–>TLS–>TCP–>IP) 85 | 3. 可扩展：由于XMPP是基于XML的，大家知道，XML命名其实是十分灵活的。而XMPP不是像传统的传二进制/文本内容，而是以XML的形式通信。所以基于XML的XMPP具有良好的扩展性 86 | 4. 弹性佳：处于移动新时代的XMPP，目前的应用范围相当广泛，除了被运用在即时通讯，还被用在游戏、远程系统监控、协同工具等等 87 | 5. 多样性：在开源社区，有许多基于XMPP搭建的开源即时通讯系统，这些各种各样的开源技术极大地丰富了XMPP协议，使得XMPP更加多样 88 | 89 | ### 缺点 90 | 1. 没有二进制数据：由上文可知，XMPP主要基于XML传输，没有二进制数据，所以一些针对二进制数据处理的方法(如base64加密)，对XMPP没有作用 91 | 2. 数据负载过重：由于以XML传输，相对于JSON，XML在移动时代就显得有点"笨重"了，这会导致用户流量消耗很快，所以若基于XMPP实现移动客户端，这一块的优化一定是必不可少的 92 | 93 | ![XMPP-3](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/XMPP3.jpg?raw=true) 94 | 95 | --- 96 | ## 参考阅读 97 | * [纪玉奇 - XMPP协议详解](http://www.cnblogs.com/jiyuqi/p/5085962.html) 98 | * [Wiki - XMPP客户端软件列表](https://zh.wikipedia.org/wiki/XMPP%E5%8D%94%E8%AD%B0%E7%9A%84%E5%AE%A2%E6%88%B6%E7%AB%AF%E8%BB%9F%E9%AB%94%E5%88%97%E8%A1%A8) 99 | * [Wiki - XMPP服务器列表](https://zh.wikipedia.org/wiki/XMPP%E5%8D%94%E8%AD%B0%E4%BC%BA%E6%9C%8D%E5%99%A8%E8%BB%9F%E9%AB%94%E5%88%97%E8%A1%A8) 100 | * [知乎 - XMPP协议是否适合移动客户端使用？](https://www.zhihu.com/question/20829401) 101 | 102 | --- 103 | * 文章更新时间：2016.6.27 104 | * 作者：Seahub 105 | -------------------------------------------------------------------------------- /link/0019.md: -------------------------------------------------------------------------------- 1 | # 浅谈网络层04之IPv4协议数据包报头 2 | * 阅读难度:中 3 | 4 | --- 5 | 6 | * 我们之前已经了解了组成网络层的重要组成部分--路由算法，现在是时候来讨论网络层的另外一大基石了，将整个Internet粘合在一起的正是网络层协议，即Internet协议（IP，Internet Protocol） 7 | 我们先来了解一下IPV4，另外的IPV6，我们会接下来继续了解 8 | 9 | ### IPv4协议 10 | * 我们先来了解一下IP数据包的格式，每个IP数据包包含两个部分，一个是头，一个是正文。头由一个20字节的定长部分和一个可选的变长组成，下面显示了IP数据包的头格式 11 | 12 | ![](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/ipheader.png) 13 | 14 | * 包头各个部分的介绍如下: 15 | * Version(版本):声明这个IP数据包的版本，例如目前惯用的IPv4其信息就反映在此处 16 | * IHL(Interner Header Length，IP报头的长度)：告知这个IP数据包的报头长度，以4字节一个单位来记录IP报头的长度 17 | * Type of Service(服务类型):这个字段现在改名成Different service (区分服务)了，这个项目的内容是“PPPDTRUU”，表示这个IP数据包的服务类型，主要分为 18 | * PPP：表示这个IP数据包的优先级，目前很少使用 19 | * D：若为0表示一般延迟(delay),若为1表示低延迟 20 | * T：若为0表示一般传输量(throughput),若为1表示高传输量 21 | * R:若为0表示一般可靠度(reliability)，若为1表示高可靠度 22 | * UU:表示并未使用 23 | * Total Length(总长度):指这个IP数据包的总容量，包括报头和数据(Data)部分，最大可达65535byte 24 | * Identification(识别码):有时候当传输层传给网络层的数据太大，一个数据报没办法全部发送完的时候，就要把数据拆分成不同的数据分段，然后到达目标主机以后就组装起来，然后要有一个标示符指出哪些数据分段是来自哪一个原数据包的，这个就是起标示符的作用了 25 | * Flags(特殊标志):这个地方内容为"0DM",其意义为： 26 | * D:若为0表示可以分段，若为1表示不可分段。这就是我们上面提到的把大数据拆分成小的数据报 27 | * M:若为0表示次IP为最后分段，若为1表示非最后分段 28 | * Fragment Offset(分段偏移):表示目前这个IP分段在原始的IP数据包中所占的位置。就有点像序号，可以理解成编程语言里面的列表的偏移量那样，有了这个序号才能将所有的小IP分段组合成原本的IP数据包大小。通过Total Length，Identification ,Flag以及Fragment Offset就能够将小IP分段在 29 | * Time To Live(TTL,生存时间):这个表示IP数据包的生存时间，范围为0-255.当这个IP数据包通过一个路由器是，TTL就会减1，当TTL为0时，这个数据包就会被丢弃，这个是为了防止数据包无限长时间地存在于网络。 30 | * Protocol Number(状态协议码):来自传输层与网络层本身的其他数据都是放置在IP数据包中的，我们可以在IP报头记载这个IP数据包中的数据是什么，在这个字段就是记录每种数据包的内容了，在这个字段记载的代码与相关的数据包协议如下（当然，我们比较常见到的还是TCP，UDP和ICMP） 31 | 32 | | IP内的代码 | 数据包协议名称(全名) | 33 | | :-------: | :----: | 34 | | 1 | IMCP(Internet Control Message Protocol) | 35 | | 2 | IGMP(Internet Group Management Protocol) | 36 | | 3 | GGP(Gateway-to-Gateway Protocol) | 37 | | 4 | IP(Ip in Ip encapsulation) | 38 | | 6 | TCP( Transmission Control Protocol) | 39 | | 8 | EGP(Exterior Gateway Protocol) | 40 | | 17 | UDP(User Datagram Protocol) | 41 | 42 | * Header Checksum(报头校验码):用于检查这IP报头是否存在错误 43 | * Source Address(来源的IP地址):这个就很容易理解吧，就是发送数据报的源主机的IP地址 44 | * Destination Address(目标主机的IP地址):有来源还需要有目标才能传送，这就是目标的IP地址 45 | * Options(其他选项):这是额外的功能了包括安全性，严格源路由，松散源路由，记录路由，时间戳等选项,其实这些选项设计出来，真的现在还在用的真的不多了 46 | * Padding(补全项目):由于Options的内容不一定是32bits，如果Options的数据不足32bits，就由Padding补全到32bits。 47 | 48 | ### 总结 49 | * 今天只是介绍了一下IPv4报头的内容，接下来我们会更深入地去了解IP这个网络层的核心部分的内容 50 | --- 51 | * 文章编写人: Samray 52 | * 最近更新时间: 2016-7-28 53 | -------------------------------------------------------------------------------- /link/001A.md: -------------------------------------------------------------------------------- 1 | # SSL/TLS PartI: Encryption 2 | * 阅读难度：低 3 | 4 | ## 聊一聊 - SSL/TLS历史 5 | * 首先要声明的一点，TLS与SSL实质上是同一样协议，主要是用于安全方面的，SSL由著名的网景公司首席科学家发明，然后被IETF（互联网工程任务小组）标准化，并更名为TLS，所以它的发展历程是这样的 6 | * SSL1.0 -> SSL2.0 -> SSL3.0 -> TLS1.0 -> TLS1.1 -> TLS1.2 -> TLS1.3(草案) 7 | * 为什么我们需要TLS/SSL?其实，互联网在早期技术不发达的时候（尤其是SSL还没出现的时候），网络通信一般都是用明文传输的。这意味什么，用户要登录一个网站，只要我通过某种方式截取用户流量/监听用户通信，进行简单分析之后，就能获取用户密码，这样的互联网是极其不安全的。 8 | * TLS/SSL主要就是用来解决这一需求：通过加密与认证，让通信更安全 9 | * 因此，TLS/SSL主要分为两个方面：加密与认证。我们这一节先对加密的SSL/TLS工作流程进行了解，下一节再一起了解认证部分 10 | * HTTPS与TLS/SSL的关系：在某种程度上说，我们可以把HTTPS理解成HTTP Over TLS/SSL，即通过TLS/SSL等安全协议，对通信进行加密，实现安全的数据传输 11 | 12 | --- 13 | 14 | ## SSL/TLS（Secure Sockets Layer/Transport Layer Security） 15 | * SSL/TLS定义：SSL/TLS是一种安全协议，目的是为互联网通信，提供安全及数据完整性保障，目的是为了降低数据的窃听、篡改以及身份的冒充风险。 16 | 17 | ![TLS_SSL1_3](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/TLS_SSL3.png?raw=true) 18 | 19 | --- 20 | ## SSL/TLS协议工作流程 21 | 1. 客户端发送Hello消息，该消息包含客户端CA证书（如果有的话）、TLS/SSL版本号、加密和压缩使用的算法，以及生成一个随机数A 22 | 2. 服务端发送Hello消息，该消息包含服务端CA证书、确认使用的TLS/SSL版本号、确认使用的加密和压缩算法，以及生成一个随机数B 23 | 3. 服务端与客户端交换证书 24 | 4. 服务端请求客户端公钥，如果客户端有证书则进行双向身份验证，没有证书就只能根据随机数生成公钥 25 | 5. 客户端与服务端通过公钥协商产生共同的主私钥，双方获得主私钥后以后就使用这个私钥来解密 26 | * 协商流程： 27 | 1. 服务端自己持有私钥，公布私钥，发送证书给客户端认证 28 | 2. 客户端对主私钥使用服务端的公钥加密 29 | 3. 服务端使用自己的私钥解开加密后的主私钥，即获得主私钥 30 | 4. 服务端与客户端之后通过主私钥进行通信 31 | 32 | ![TLS_SSL1_2](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/TLS_SSL2.png?raw=true) 33 | 34 | 6. 客户端确认开始加密 35 | 7. 服务端确认开始加密 36 | 8. 发送加密数据 37 | 38 | ![TLS_SSL1_1](https://github.com/SeaHub/BlogOfComputerNetwork/blob/master/res/TLS_SSL1.jpg?raw=true) 39 | 40 | --- 41 | ## SSL/TLS的特性 42 | * 保密性：TLS/SSL以一种非对称加密的手段来对通信数据进行加密 43 | * 可靠性：服务端会被认证CA证书，保证服务端为正规服务端 44 | * 完整性：TLS/SSL对数据会进行完整性检查 45 | 46 | --- 47 | ## 参考阅读 48 | * [SSL与TLS的区别（个人认为可以归属到版本区别）](http://hengstart.iteye.com/blog/840561) 49 | * [Youtube - How SSL works tutorial](https://www.youtube.com/watch?v=iQsKdtjwtYI) 50 | * [Youtube - SSL TLS HTTPS process explained in 7 minutes](https://www.youtube.com/watch?v=4nGrOpo0Cuc) 51 | 52 | --- 53 | * 文章更新时间：2016.7.28 54 | * 作者：Seahub 55 | -------------------------------------------------------------------------------- /res/Compare.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/Compare.png -------------------------------------------------------------------------------- /res/DNS1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/DNS1.png -------------------------------------------------------------------------------- /res/DNS2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/DNS2.png -------------------------------------------------------------------------------- /res/FTP1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/FTP1.gif -------------------------------------------------------------------------------- /res/FTP2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/FTP2.png -------------------------------------------------------------------------------- /res/FTP3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/FTP3.jpg -------------------------------------------------------------------------------- /res/OSI.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/OSI.png -------------------------------------------------------------------------------- /res/POP3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/POP3.png -------------------------------------------------------------------------------- /res/POP3transform.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/POP3transform.jpg -------------------------------------------------------------------------------- /res/SOAP1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/SOAP1.png -------------------------------------------------------------------------------- /res/SOAP2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/SOAP2.jpg -------------------------------------------------------------------------------- /res/TCPClose.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/TCPClose.png -------------------------------------------------------------------------------- /res/TCPCreate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/TCPCreate.png -------------------------------------------------------------------------------- /res/TLS_SSL1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/TLS_SSL1.jpg -------------------------------------------------------------------------------- /res/TLS_SSL2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/TLS_SSL2.png -------------------------------------------------------------------------------- /res/TLS_SSL3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/TLS_SSL3.png -------------------------------------------------------------------------------- /res/UDP Header.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/UDP Header.jpg -------------------------------------------------------------------------------- /res/UDP Helper.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/UDP Helper.jpg -------------------------------------------------------------------------------- /res/UDP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/UDP.png -------------------------------------------------------------------------------- /res/XMPP1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/XMPP1.gif -------------------------------------------------------------------------------- /res/XMPP2-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/XMPP2-5.png -------------------------------------------------------------------------------- /res/XMPP2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/XMPP2.png -------------------------------------------------------------------------------- /res/XMPP3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/XMPP3.jpg -------------------------------------------------------------------------------- /res/Yesky-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/Yesky-1.png -------------------------------------------------------------------------------- /res/Yesky-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/Yesky-2.png -------------------------------------------------------------------------------- /res/aloha.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/aloha.png -------------------------------------------------------------------------------- /res/chrome-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/chrome-1.png -------------------------------------------------------------------------------- /res/chrome-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/chrome-2.png -------------------------------------------------------------------------------- /res/cmd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/cmd.png -------------------------------------------------------------------------------- /res/cmd2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/cmd2.png -------------------------------------------------------------------------------- /res/compare.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/compare.png -------------------------------------------------------------------------------- /res/comparility.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/comparility.png -------------------------------------------------------------------------------- /res/con.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/con.png -------------------------------------------------------------------------------- /res/correct_code1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/correct_code1.png -------------------------------------------------------------------------------- /res/cti.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/cti.png -------------------------------------------------------------------------------- /res/datagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/datagram.png -------------------------------------------------------------------------------- /res/dvr.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/dvr.png -------------------------------------------------------------------------------- /res/envirnment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/envirnment.png -------------------------------------------------------------------------------- /res/iPv4 Header.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/iPv4 Header.png -------------------------------------------------------------------------------- /res/imap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/imap.png -------------------------------------------------------------------------------- /res/ipheader.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/ipheader.png -------------------------------------------------------------------------------- /res/par.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/par.png -------------------------------------------------------------------------------- /res/popvsimap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/popvsimap.png -------------------------------------------------------------------------------- /res/relationship.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/relationship.png -------------------------------------------------------------------------------- /res/routing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/routing.png -------------------------------------------------------------------------------- /res/smtp1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/smtp1.gif -------------------------------------------------------------------------------- /res/smtp2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/smtp2.jpg -------------------------------------------------------------------------------- /res/summary.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/summary.png -------------------------------------------------------------------------------- /res/telent1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/telent1.gif -------------------------------------------------------------------------------- /res/telent2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/telent2.jpg -------------------------------------------------------------------------------- /res/vc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/vc.png -------------------------------------------------------------------------------- /res/window.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SeaHub/BlogOfComputerNetwork/f7139ea7ce34a24e085fb80080480032489c57dc/res/window.png --------------------------------------------------------------------------------