一、基本慨念:
IP地址 =网络号+主机号.
域名系统：
是一个分布数据库，它提供将主机名（就是网址啦）转换成IP地址的服务或IP转成主机名。
RFC：
就是tcp/ip协议的标准文档现在它一共有4000多个协议的定义，当然，我们所要学习的，也就是那么十几个协议而已。
Port:注意，这个号码是用在TCP，UDP上的一个逻辑号码，并不是一个硬件端口，我们平时说把某某端口封掉了，也只是在
IP层次把带有这个号码的IP包给过滤掉了而已。
编程接口:
有socket和TLI。而前面的有时候也叫做“Berkeley socket”，可见Berkeley对于网络的发展有多大的贡献。
二、数据链路层
作用：
1.为IP模块发送和 接收IP数据报。
2.为ARP模块发送ARP请求和接收ARP应答。
3.为RARP模块发送RARP请求和接收RARP应答。
这一层协议：
1. 以太网（就是平时我们用的网卡）协议。
2. 相当普及的PPP协议（就是adsl宽带），以及一个loopback协议
Linux里面的ifconfig -a命令，可以看到：
eth0 Link encap:Ethernet HWaddr 00:01:4A:03:5B:ED
inet addr:192.168.11.2 Bcast:192.168.11.255 Mask:255.255.255.0 //eth0 以太网接口
inet6 addr: fe80::201:4aff:fe03:5bed/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2819 errors:0 dropped:0 overruns:0 frame:0
TX packets:76 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:241609 (235.9 KiB) TX bytes:9596 (9.3 KiB)
lo Link encap:Local Loopback //lo则是loopback接口
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2713 errors:0 dropped:0 overruns:0 frame:0
TX packets:2713 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3516032 (3.3 MiB) TX bytes:3516032 (3.3 MiB)
以太网（Ether-net）: 这个标准里面使用了一种称作CSMA/CD的接入方法,而IEEE802提供的标准集802.3(还有一部分定义
到了802.2中)也提供了一个CSMA/CD的标准,在这里面TCP/IP协议对这种情况的处理方式如下：
1.他们封装在：格式可参考其他。
以太网的IP数据报 -> RFC894中定义
IEEE802网络的IP数据报 -> RFC1042中定义(在TCP/IP 中处于配角的地位)
2.一台主机一定要能发送和接收RFC894定义的数据报.
3.一台主机可以接收RFC894和RFC1042的封装格式的混合数据报.
4.一台主机也许能够发送RFC1042数据报,如果主机能同时发送两种类型的分组数 据，那么发送的分组必须是可以
设置的，而且默认条件下必须是RFC 894分组
PPP协议(点对点协议)是从SLIP的替代品。他们都提供了一种低速接入的解决方案.
而每一种数据链路层协议，都有一个MTU（最大传输单元）定义，在这个定义下面，如果IP数据报过大，则要进行
分片(fragmentation)，使得每片都小于MTU，注意PPP的MTU并不是一个物理定义，而是指一个逻辑定义（个人认为
就是用程序控制）。
linux 下 netstat -in 命令：
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 1774 0 0 0 587 0 0 0 BMRU //eth0的MTU是1500
lo 16436 0 2667 0 0 0 2667 0 0 0 LRU//lo（环回接口)16436
loopback协议(环回接口):Loopback接口是一个虚拟网络接口，在不同的领域，其含义也大不一样.在TCP/IP中回环设备是一
个通过软件实现的虚拟网络接口，它不与任何硬件相关联。loopback接口一般被完整的集成在计算
机系统的内部网络框架中。
平时我们用127.0.0.1来尝试自己的机器服务器好使不好使,走的就是这个loopback接口。
对于环回接口，有如下三点值得注意:
1.传给环回地址（一般是127.0.0.1）的任何数据均作为IP输入。
2.传给广播地址或多播地址的数据报复制一份传给环回接口，然后送到以太网上。这是 因为广播传送和多播
传送的定义包含主机本身。
3.任何传给该主机IP地址的数据均送到环回接口。
三、IP协议ARP协议和RARP协议
1.IP协议:
IP不是可靠的协议，这是说，IP协议没有提供一种数据未传达以后的处理机制--这被认为是上层协议--TCP或
UDP要做的事情。
1.1.IP协议头（图略）：那8位的TTL字段，规定该数据包在穿过多少个路由之后才会被抛弃（每次减一）这里就体现出来IP协议包的不可靠性，它不保证数据被送达
tranceroute的-m选项要求最大值是255。
1.2.IP路由选择：（关于路由表等问题这里不详谈）
1.3.子网寻址：现在所有的主机都要求子网编址，主机号 分成“子网号+主机号”， 故：
IP 地址 = 子网号+主机号
如 IP ： 192.168.0.45 // "192.168" 为网络号 ，"0"为子网号,"45"为主机号
子网掩码的作用:用来判断任意两个IP地址是否属于同一子网络，这时只有在同一子网的计算机才能"直接"互通
2. ARP协议：
当主机要发送一个IP包的时候，会首先查一下自己的ARP高速缓存(就是一个IP-MAC地址对应表缓存)，如果查询的IP-MAC
值对不存在，那么主机就向网络发送一个ARP协议广播包，这个广播包里面就有待查询的IP地址，而直接收到这份广播的
包的所有主机都会查询自己的IP地址，如果收到广播包的某一个主机发现自己符合条件，那么就准备好一个包含自己的
MAC地址的ARP包传送给发送ARP广播的主机，而广播主机拿到ARP包后会更新自己的ARP缓存(就是存放IP-MAC对应表的地方)。
四、ICMP(网络控制报文)协议，ping和Traceroute
当传送IP数据包发生错误，比如主机不可达，路由不可达等等，ICMP协议将会把错误信息封包，然后传送回给主机。
给主机一个处理错误的机会，这也就是为什么说建立在IP层以上的协议是可能做到安全的原因。
ICMP数据包 = 错误类型（8bit）+代码（8bit）+校验和（16bit）
尽管在大多数情况下，错误的包传送应该给出ICMP报文，但是在特殊情况下，是不产生ICMP错误报文的。如下：
1. ICMP差错报文不会产生ICMP差错报文（出IMCP查询报文）（防止IMCP的无限产生和传送）
2. 目的地址是广播地址或多播地址的IP数据报。
3. 作为链路层广播的数据报。
4. 不是IP分片的第一片。
5. 源地址不是单个主机的数据报。这就是说，源地址不能为零地址、环回地址、广播地 址或多播地址。
ICMP协议大致分为两类，一种是查询报文，一种是差错报文
查询报文有：
1.ping查询（不要告诉我你不知道ping程序）
2.子网掩码查询（用于无盘工作站在初始化自身的时候初始化子网掩码）
3.时间戳查询（可以用来同步时间）
五、UDP协议
UDP协议并不提供超时重传，出错重传等功能，也就是说其是不可靠的协议。
1.UDP端口号
2.UDP检验和:这是一个可选的选项，并不是所有的系统都对UDP数据包加以检验和数据(相对TCP协议的必须来说)
3.UDP长度:UDP可以很长很长，可以有65535字节那么长。但是一般网络在传送的时候，一次一般传送不了那么长的协议
（涉及到MTU的问题）
六、广播和多播，IGMP协议
1.单播(unicast)
2.广播(unicast)
A类网址的广播就是 netid.255.255.255，如果是子网，则是netid.netid.subnetid.255；
B类IP则是则是 netid.netid.255.255。广播所用的MAC地址FF-FF-FF-FF-FF-FF。
3.多播(multicast)
多播的MAC地址是最高字节的低位为1，例 如01-00-00-00-00-00。多播组的地址是D类IP，规定是
224.0.0.0-239.255.255.255。
原理：多播的数据还是要通过数据链路层进行MAC地址绑定然后进行发送。所以一个以太网卡在绑定了一个多播IP地址之后，
必定还要绑定一个多播的MAC地址，
4.IGMP协议
IGMP的作用：让其他所有需要知道自己处于哪个多播组的主机和路由器知道自己的状态。一般多播路由器根本不需要
知道某一个多播组里面有多少个主机，而只要知道自己的子网内还有没有处于某个多播组的主机就可以了。只要某一个多
播组还有一台主机，多播路由器就会把数据传输出去，这样，接受方就会通过网卡过滤功能来得到自己想要的数据。为了
知道多播组的信息，多播路由器需要定时的发送IGMP查询。
七.TCP协议概述(重点)
1.简单工作原理：
1.应用数据被分割成TCP认为最适合发送的数据块，由TCP传递给IP的信息单位称为报文段或段（ segment）
2.当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能 及时收到一个确认，将重发这
个报文段。（自适应的超时及重传策略）
3.当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
4.TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输 过程中的任何变化。如果收到
段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）
5.既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段 的到达也可能会失序。如果必要，
TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
6.TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能
接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
-> 1.可以看出，TCP中保持可靠性的方式就是“超时重发”，虽然TCP也可以用各种各样的ICMP报文来处理这些，但是这也不
是可靠的，最可靠的方式就是只要不得到确认，就重新发送数据报，直到得到对方的确认为止。
2.TCP的首部和UDP首部一样，都有发送端口号和接收端口号。但是显然，TCP的首部信息要比UDP的多，可以看到，TCP协
议提供了发送和确认所需要的所有必要的信息。
2. TCP数据的发送过程:
• 双方建立连接
• 发送方给接受方TCP数据报，然后等待对方的确认TCP数据报，如果没有，就重新发，如果有，就发送下一个数据报。
• 接受方等待发送方的数据报，如果得到数据报并检验无误，就发送ACK(确认)数据报，并等待下一个TCP数据报的到来。
直到接收到FIN(发送完成数据报)
• 中止连接
八.DNS域名系统
Domain Name System
最初的DNS系统使用的是一个巨大的hosts.txt文件（很吃惊，用 这个就好使了？），可是一段时间以后，开发这就不得不用
数据库来代替hosts.txt文件，最终发展到了现在的分布式数据库。
一个独立管理的DNS子树叫做zone，最常见的区域就是二级域名，比如说.com.cn。我们还可以把这个二级域名给划分成更小
的区域，比如说sina.com.cn。
DNS报文定义可以参考相关的手册或资料。
DNS服务器高速缓存
BIND9默认是作为一个高速缓存服务器，其将所有的查询都转交到根服务器去，然后得到结果并放在本地的缓冲区，以加快查
询速度。如果有兴趣可以安装一个BIND9来尝试一下。而自己定义的zone则可以规定其在缓存中的时间，一般是1天（就是配置
文件中的1D）。
用UDP还是TCP
DNS服务器支持TCP和UDP两种协议的查询方式，而且端口都是53。而大多数的查询都是UDP查询的，一般需要TCP查询的有两种情况：
当查询数据多大以至于产生了数据截断(TC标志为1)，这时，需要利用TCP的分片能力来进行数据传输（看TCP的相关章节）。
当主（master）服务器和辅（slave）服务器之间通信，辅服务器要拿到主服务器的zone信息的时候。
九.TCP的状态迁移图
1.客户端应用程序的状态迁移图
客户端的状态可以用如下的流程来表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端
就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2
等状态，这些状态的迁移就是前面提到的结束连接的四次握手。
2.服务器的状态迁移图
服务器的状态可以用如下的流程来表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后（注意不是
第四次）。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。
3.其他状态迁移
书中的图还有一些其他的状态迁移，这些状态迁移针对服务器和客户端两方面的总结如下
//LISTEN->SYN_SENT，对于这个解释就很简单了，服务器有时候也要打开连接的嘛。
//SYN_SENT->SYN收到，服务器和客户端在SYN_SENT状态下如果收到SYN数据报，则都需要发送SYN的ACK数据报并把自己的状态调整
到SYN收到状态，准备进入ESTABLISHED
//SYN_SENT->CLOSED，在发送超时的情况下，会返回到CLOSED状态。
//SYN_收到->LISTEN，如果受到RST包，会返回到LISTEN状态。
//SYN_收到->FIN_WAIT_1，这个迁移是说，可以不用到ESTABLISHED状态，而可以直接跳转到FIN_WAIT_1状态并等待关闭。
4.2MSL等待状态
书中给的图里面，有一个TIME_WAIT等待状态，这个状态又叫做2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进
入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的
保险状态）。这个状态在很大程度上保证了双方都可以正常结束，但是，问题也来了。
由于插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是无法再次使用同一个插口的，对于客户程
序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插
口被使用）。为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服
务器还是要平静的等待2MSL时间的过去才能进行下一次连接。
5.FIN_WAIT_2状态
这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，
但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来
决定关闭这个状态。