计算机网络知识全介绍
2013-05-14 17:12:07 
阿炯
计算机网络，它是计算机技术与通信技术两个领域的结合。
一、计算机网络概述
1.1 计算机网络的分类
按照网络的作用范围：广域网(WAN)、城域网(MAN)、局域网(LAN)；
按照网络使用者：公用网络、专用网络。
1.2 计算机网络的层次结构
TCP/IP四层模型与OSI体系结构对比：
1.3 层次结构设计的基本原则
各层之间是相互独立的；
每一层需要有足够的灵活性；
各层之间完全解耦。
1.4 计算机网络的性能指标
速率：bps=bit/s，时延：发送时延、传播时延、排队时延、处理时延往返时间，RTT：数据报文在端到端通信中的来回一次的时间。
认识网络速率单位
在电信IDC合同中或交换机流量查看中，所看到的数值，这些究竟是多大呢，如何直观地理解它们呢。
在计算机科学中，bit是表示信息的最小单位，叫做二进制位，一般用0和1表示。Byte叫做字节，由8个位(8bit)组成一个字节(1Byte)，用于表示计算机中的一个字符。bit与Byte之间可以进行换算，其换算关系为：1Byte=8bit(或简写为：1B=8b)；在实际应用中一般用简称，即1bit简写为1b(注意是小写英文字母b)，1Byte简写为1B(注意是大写英文字母B)。
在计算机网络或者是网络运营商中，一般宽带速率的单位用bps(或b/s)表示；bps表示比特每秒即表示每秒钟传输多少位信息，是bit per second的缩写。在实际所说的1M带宽的意思是1Mbps(是兆比特每秒Mbps不是兆字节每秒MBps)。
建议用户记住以下换算公式：
1B=8b 1B/s=8b/s(或1Bps=8bps)
1KB=1024B 1KB/s=1024B/s
1MB=1024KB 1MB/s=1024KB/s
规范提示：实际书写规范中B应表示Byte(字节)，b应表示bit(比特)，但在平时的实际书写中有的把bit和Byte都混写为b，如把Mb/s和MB/s都混写为Mb/s，导致人们在实际计算中因单位的混淆而出错。
实例：在我们实际上网应用中，下载软件时常常看到诸如下载速度显示为128KBps(KB/s)，103KB/s等等宽带速率大小字样，因为ISP提供的线路带宽使用的单位是比特，而一般下载软件显示的是字节(1字节＝8比特)，所以要通过换算，才能得实际值。然而我们可以按照换算公式换算一下：
128KB/s=128×8(Kb/s)=1024Kb/s=1Mb/s 即 128KB/s=1Mb/s。
所谓1M带宽，其实是指1Mbps(每秒百万位元)线路速度，而其下载速度计算方式是1x1024/8=128KB/sec(每秒128位元组)，但这只是理论上的速度，因为在实际应用上，还要再减去一定的网络速率的损耗。
据TMnet Streamyx官方网站披露，除了以太网络标头值(Ethernet Header)之外，这些流失因素包括传输控制协议标头值(TCP Header)有5至10％的传输控制消耗，而异步传输模式标头值(ATM Header)则多达15％。 因此：1M宽带的实际上网速度是1乘以1024和除去8，得出128KB/s再乘75％，等于96KB/s，就是你的1M宽带网络的真正数据传输速率。
目前我国宽带上网速度介于512Kbps至2Mbps之间。同样的道理，在2M或512K也是一样，512K则是512Kbps(每秒千位元)。以此计算的话，我们可以粗略得出目前宽频的实际下载速度：
宽频线路速度 理想下载速度 实际下载速度
2Mbps 256KB/s 192KB/s
1Mbps 128KB/s 96KB/s
512Kbps 64KB/s 48KB/s
一般说来，带宽越大，下载速度就越快，但下载速度除受服务供应商因素所影响外，用户本身所使用操作系统、浏览器及电脑配备等因素，亦可影响宽频速度，其中又以最大传输单位(Maximum Transmission Unit，MTU)设定错误问题最为常见。
1Mbps是多少兆？
1Mbps=1024Kbps=1024/8KBps=128KB/s
1M的宽带最高下载速度可以达到128K/s，但是这只是最高极限速度，考虑一些其它因素如链路的质量、计算机或接收软件的处理能力及传输过程中的开销。假如是10M宽带，10M=10240Kbps=1280KB/s，这个1280kb/s就是最大的下载网速。所以1Mbps就是1兆，在电脑中，1M的宽带在下载文件时，平均下载速率就是100KB/s。
每秒千位元或百万位元：Mbps其实是指每秒百万位元(Megabits per second)，而Kbps则是每秒千位元(Kilobits per second)。
也许你会问：“位元又是什么？”其实，电脑是以bit(位元)和Byte(位元组)作为计算单位。bit是“binary digit”的缩写，它是电脑辨识讯息的最小单位，再上一个更大的单位为位元组(byte)。由于八个位元一组(8 bits = 1 byte)，我们常在电脑打的每一个字体或符号等资料，通常会以位元组的方式来打包。一个位元组代表示一个字符，例如“Q”、“4”或“，”等，都属于一个位元组。
正如长度计算单位的公尺(Meter，M)和公里(Kilometer，KM)的情况一样，电脑将位元组的一千倍称作KB(Kilobyte)，而KB的一千倍为MB(Megabyte)。
当然，一千倍是笼统的说法。由于电脑使用的是二进位系统，准确的倍数计算法是二的十次方，因此1KB相等于1024个位元组。
KB和Kb大小写意义不同
一般用来上网的数据机及网络通讯的传输速率都是以“bps”为单位，例如14.4Kbps，28.8Kbps，56Kbps，1Mbps及2Mbps等等。无论用作电脑储存或网络速度的计算单位，Kb/s和KB/s英文字母大写和小写之意义截然不同，这是许多人常会犯错的地方。
大写的B代表位元组(Byte)，小写的b则代表位元(bit)，所以MB(Megabyte)是百万位元组，Mb(megabit)是百万位元；KB/s是每秒千位元组，而Kbps则是每秒千位元。
网络速度单位之间关系：
●Kb/s＝每秒千位元，用于线路速度。
●KB/s＝每秒千位元组，用于下载速度。
●1KB/s = 8Kb/s
●1 Byte(位元组) = 8 bits(位元)
●1 Kb(千位元) = 1024 bit(位元)s
●1 KB(千位元组) = 1024 bytes(位元组)
●1 Mb (百万位元)= 1024 Kb(位元)
●1 MB(百万位元组) = 1024 KB(位元组)
MB和Mb、MB/s和Mb/s是有区别的。
其中大B代表Byte(字节)，小b代表bit(比特或位)。
1 Kb = 1024 bit
1 KB = 1024 Byte
1 Mb = 1024 Kb
1 MB = 1024 KB
1 Byte = 8 bit
1 MB = 8Mb
1 Mb = 0.125 MB
数据传输率的单位一般采用MB/s或Mb/s。在数据传输率上官方数据中(如电信部门)一般采用Mb/s为单位，而下载软件(如IE、迅雷、快车)一般采用MB、KB/s为单位。
宽带最高下载理论值：
1Mb/s = 0.125MB/s = 128KB/s
电信部门说的1M宽带的M是指Mb/s，下载软件时的传输率是MB/S，也就是1M宽带下载速度最快128KB/s，再去掉损耗也就是120KB/s左右。按这个说法10M的宽带最快下载速度是1.25MB/s，100M的局域网宽带最快下载速度是12.5MB/s。
MB/s的含义是兆字节每秒，Mb/s的含义是兆比特每秒，前者是指每秒传输的字节数量，后者是指每秒传输的比特位数，二者是完全不同的。Byte是字节数，bit是位数，在计算机中每八位为一字节，也就是1Byte＝8bit，是1：8的对应关系，因此1MB/s等于8Mb/s。因此在在书写单位时一定要注意B字母的大小写，此时B字母的大小真可以称为失之毫厘，谬以千里。
网络技术中的 10M 带宽指的是以位计算，就是 10Mbit/秒，而下载时的速度看到的是以字节(Byte)计算的，所以 10M 带宽换算成字节理论上最快下载速度为: 1.25 MByte/秒
在计算机/通讯行业中，计算数据传送速度也使用十进制来衡量。
在数据存储容量计算中，一般采用二进制来衡量。1MB=1024K=1024*1024B。
根据进制规定，传送速度可以有两种表示方法 bps和Bps，但是他们是有严格区别。Bps中的B使用的是二进制系统中的Byte字节，bps中的b是十进制系统中的位元。在我们常说的56K拨号，100M局域网都是bps计量，当用于软件下在时，下载工具一般又以Bps计算，所以它们之间有8bit=1Byte的换算关系。
MB和MiB的区别
MB：单位以10为底数的指数：
1KB=10^3 =1000,
1MB=10^6=1000000=1000KB
1GB=10^9=1000000000=1000MB
MiB：是以2为底数的指数：
1KiB=2^10=1024,
1MiB=2^20=1048576=1024KiB
1GiB=2^30=1,073,741,824=1024MiB
在计算机领域以前常说的KB，MB和GB跟KiB，MiB和GiB是完全一样的。KiB，MiB和GiB这三个标志是标准的计算机领域的术语，中间的i取自binary，表示二进制幂的计数：
1KiB = 1024 Byte
1MiB = 1024 KiB = 1048576 Byte
1GiB = 1024 MiB
1TiB = 1024 GiB
1999年，国际电工委员会（IEC）公布了修正2：“IEC 60027-2：电工技术应用的字母符号 -- 第二部分：通信和电子。”
该标准在1998年通过，介绍了词头“kibi-”、“mebi-”、“gibi-”、“tebi-”、“pebi-”、“exbi-”，作为二进制乘幂的计数方法。要读懂这段规定，其内涵是定义了符号的规范用法。Mi、Ki、Gi代表的是二进制乘幂的计数方法。反过来讲，就是规范了一个标准，只要出现上述标志的，意味着这种使用是规范的。而我们日常使用的MB、KB等用法存在着很多歧义。这种硬性规定是出于学术上的考虑的。在实际使用中，MB的意义和MiB应该是等同的。
不过在通信领域的日常口语中，KB，MB和GB就不一定是二进制幂的表示。K就是1000，M就是1000*1000。
还要注意一个细节，一般B大写指Byte，b小写指bit。在计算机领域，B一般都是大写的。
使用iperf检查带宽
吉比特以太网理论上的限制是 128MBit/s。这个数字从何而来，看看这些计算：
1Gb = 1024Mb；1024Mb/8 = 128MB；'b' = 'bits'、'B' = 'bytes'
但实际看到的是什么呢，有什么好的测量方法呢？推荐一个工具 iperf。需要在两台机器上均安装此工具，或者在两个节点上编译并安装。我将在两个节点的 freeoa 用户的主目录中编译它：
tar zxvf iperf-2.0.2.tar.gz
cd iperf-2.0.2
./configure --prefix=/home/freeoa/iperf
make
make install
在一台机器上运行：
# /home/freeoa/iperf/bin/iperf -s -f M
这台机器将用作服务器并以 MBit/s 为单位输出执行速度。
在另外一台节点上，运行：
# /home/freeoa/perf/bin/iperf -c the-mac-name -P 4 -f M -w 256k -t 60
两个屏幕上的结果都指示了速度是多少。在使用吉比特适配器的普通服务器上，可能会看到速度约为 112MBit/s。这是 TCP 堆栈和物理电缆中的常用带宽。通过以端到端的方式连接两台服务器，每台服务器使用两个独立的以太网卡，获得了约 220MBit/s 的带宽。事实上，在内部网络上看到的 NFS 约为 150-160MBit/s，这仍然表示带宽可以达到预期效果。如果看到更小的值，则应该检查是否有问题。
二、物理层
物理层的作用：连接不同的物理设备，传输比特流。该层为上层协议提供了一个传输数据的可靠的物理媒体。简单的说，物理层确保原始的数据可在各种物理媒体上传输。
物理层设备：
中继器【Repeater，也叫放大器】：同一局域网的再生信号；两端口的网段必须同一协议；5-4-3规程：10BASE-5以太网中，最多串联4个中继器，5段中只能有3个连接主机；
集线器：同一局域网的再生、放大信号(多端口的中继器)；半双工，不能隔离冲突域也不能隔离广播域。
信道的基本概念：信道是往一个方向传输信息的媒体，一条通信电路包含一个发送信道和一个接受信道。
单工通信信道：只能一个方向通信，没有反方向反馈的信道；
半双工通信信道：双方都可以发送和接受信息，但不能同时发送也不能同时接收；
全双工通信信道：双方都可以同时发送和接收。
三、数据链路层
3.1 数据链路层概述
数据链路层在物理层提供的服务的基础上向网络层提供服务，其最基本的服务是将源自网络层来的数据可靠地传输到相邻节点的目标机网络层。数据链路层在不可靠的物理介质上提供可靠的传输。
该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
有关数据链路层的重要知识点：
数据链路层为网络层提供可靠的数据传输；
基本数据单位为帧；
主要的协议：以太网协议；
两个重要设备名称：网桥和交换机。
封装成帧：“帧”是数据链路层数据的基本单位：
透明传输：“透明”是指即使控制字符在帧数据中，但是要当做不存在去处理。即在控制字符前加上转义字符ESC。
3.2 数据链路层的差错监测
差错检测：奇偶校验码、循环冗余校验码CRC
奇偶校验码–局限性：当出错两位时，检测不到错误。
循环冗余检验码：根据传输或保存的数据而产生固定位数校验码。
3.3 最大传输单元MTU
最大传输单元MTU(Maximum Transmission Unit)，数据链路层的数据帧不是无限大的，数据帧长度受MTU限制.
路径MTU：由链路中MTU的最小值决定。
3.4 以太网协议详解
MAC地址：每一个设备都拥有唯一的MAC地址，共48位，使用十六进制表示。
以太网协议：是一种使用广泛的局域网技术，是一种应用于数据链路层的协议，使用以太网可以完成相邻设备的数据帧传输：
局域网分类：
Ethernet以太网IEEE802.3：
以太网第一个广泛部署的高速局域网
以太网数据速率快
以太网硬件价格便宜，网络造价成本低
以太网帧结构：
类型：标识上层协议(2字节)
目的地址和源地址：MAC地址(每个6字节)
数据：封装的上层协议的分组(46~1500字节)
CRC：循环冗余码(4字节)
以太网最短帧：以太网帧最短64字节；以太网帧除了数据部分18字节；数据最短46字节；
MAC地址(物理地址、局域网地址)
MAC地址长度为6字节，48位；
MAC地址具有唯一性，每个网络适配器对应一个MAC地址；
通常采用十六进制表示法，每个字节表示一个十六进制数，用 - 或 : 连接起来；
MAC广播地址：FF-FF-FF-FF-FF-FF。
四、网络层
网络层的目的是实现两个端系统之间的数据透明传送，具体功能包括寻址和路由选择、连接的建立、保持和终止等。数据交换技术是报文交换(基本上被分组所替代)：采用储存转发方式，数据交换单位是报文。
网络层中涉及众多的协议，其中包括最重要的协议，也是TCP/IP的核心协议——IP协议。IP协议非常简单，仅仅提供不可靠、无连接的传送服务。IP协议的主要功能有：无连接数据报传输、数据报路由选择和差错控制。
与IP协议配套使用实现其功能的还有地址解析协议ARP、逆地址解析协议RARP、因特网报文协议ICMP、因特网组管理协议IGMP。具体的协议我们会在接下来的部分进行总结，有关网络层的重点为：
网络层负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能；
基本数据单位为IP数据报；
包含的主要协议：
IP协议(Internet Protocol，因特网互联协议);
ICMP协议(Internet Control Message Protocol，因特网控制报文协议);
ARP协议(Address Resolution Protocol，地址解析协议);
RARP协议(Reverse Address Resolution Protocol，逆地址解析协议)。
重要的设备：路由器。
路由器相关协议
4.1 IP协议详解
IP网际协议是 Internet 网络层最核心的协议。虚拟互联网络的产生：实际的计算机网络错综复杂；物理设备通过使用IP协议，屏蔽了物理网络之间的差异；当网络中主机使用IP协议连接时，无需关注网络细节，于是形成了虚拟网络。
IP协议使得复杂的实际网络变为一个虚拟互联的网络；并且解决了在虚拟网络中数据报传输路径的问题。
其中，版本指IP协议的版本，占4位，如IPv4和IPv6；首部位长度表示IP首部长度，占4位，最大数值位15；总长度表示IP数据报总长度，占16位，最大数值位65535；TTL表示IP数据报文在网络中的寿命，占8位；协议表明IP数据所携带的具体数据是什么协议的，如TCP、UDP。
4.2 IP协议的转发流程
4.3 IP地址的子网划分
A类(8网络号+24主机号)、B类(16网络号+16主机号)、C类(24网络号+8主机号)可以用于标识网络中的主机或路由器，D类地址作为组广播地址，E类是地址保留。
4.4 网络地址转换NAT技术
用于多个主机通过一个公有IP访问访问互联网的私有网络中，减缓了IP地址的消耗，但是增加了网络通信的复杂度。
NAT 工作原理：
从内网出去的IP数据报，将其IP地址替换为NAT服务器拥有的合法的公共IP地址，并将替换关系记录到NAT转换表中；
从公共互联网返回的IP数据报，依据其目的的IP地址检索NAT转换表，并利用检索到的内部私有IP地址替换目的IP地址，然后将IP数据报转发到内部网络。
4.5 ARP协议与RARP协议
地址解析协议 ARP(Address Resolution Protocol)：为网卡(网络适配器)的IP地址到对应的硬件地址提供动态映射。可以把网络层32位地址转化为数据链路层MAC48位地址。
ARP 是即插即用的，一个ARP表是自动建立的，不需要系统管理员来配置。
RARP(Reverse Address Resolution Protocol)协议指逆地址解析协议，可以把数据链路层MAC48位地址转化为网络层32位地址。
4.6 ICMP协议详解
网际控制报文协议(Internet Control Message Protocol)，可以报告错误信息或者异常情况，ICMP报文封装在IP数据报当中。
ICMP协议的应用：
Ping应用：网络故障的排查；
Traceroute应用：可以探测IP数据报在网络中走过的路径。
4.7网络层的路由概述
关于路由算法的要求：正确的完整的、在计算上应该尽可能是简单的、可以适应网络中的变化、稳定的公平的。
自治系统AS：指处于一个管理机构下的网络设备群，AS内部网络自治管理，对外提供一个或多个出入口，其中自治系统内部的路由协议为内部网关协议，如RIP、OSPF等；自治系统外部的路由协议为外部网关协议，如BGP。
静态路由：人工配置，难度和复杂度高；
动态路由：
链路状态路由选择算法LS：向所有隔壁路由发送信息收敛快；全局式路由选择算法，每个路由器计算路由时，需构建整个网络拓扑图；利用Dijkstra算法求源端到目的端网络的最短路径；Dijkstra(迪杰斯特拉)算法
距离-向量路由选择算法DV：向所有隔壁路由发送信息收敛慢、会存在回路；基础是Bellman-Ford方程(简称B-F方程)；
4.8 内部网关路由协议之RIP协议
路由信息协议 RIP(Routing Information Protocol)【应用层】，基于距离-向量的路由选择算法，较小的AS(自治系统)，适合小型网络；RIP报文，封装进UDP数据报。
RIP协议特性：
RIP在度量路径时采用的是跳数(每个路由器维护自身到其他每个路由器的距离记录)；
RIP的费用定义在源路由器和目的子网之间；
RIP被限制的网络直径不超过15跳；
和隔壁交换所有的信息，30主动一次(广播)。
4.9 内部网关路由协议之OSPF协议
开放最短路径优先协议 OSPF(Open Shortest Path First)【网络层】，基于链路状态的路由选择算法(即Dijkstra算法)，较大规模的AS ，适合大型网络，直接封装在IP数据报传输。
OSPF协议优点：
安全；
支持多条相同费用路径；
支持区别化费用度量；
支持单播路由和多播路由；
分层路由。
RIP与OSPF的对比(路由算法决定其性质)：
4.10外部网关路由协议之BGP协议
BGP(Border Gateway Protocol)边际网关协议【应用层】：是运行在AS之间的一种协议,寻找一条好路由：首次交换全部信息，以后只交换变化的部分,BGP封装进TCP报文段.
五、传输层
第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。
传输层的任务是根据通信子网的特性，最佳的利用网络资源，为两个端系统的会话层之间，提供建立、维护和取消传输连接的功能，负责端到端的可靠数据传输。在这一层，信息传送的协议数据单元称为段或报文。
网络层只是根据网络地址将源结点发出的数据包传送到目的结点，而传输层则负责将数据可靠地传送到相应的端口。
有关网络层的重点：
传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制问题；
包含的主要协议：TCP协议(Transmission Control Protocol，传输控制协议)、UDP协议(User Datagram Protocol，用户数据报协议)；
重要设备：网关。
5.1 UDP协议详解
UDP(User Datagram Protocol: 用户数据报协议)，是一个非常简单的协议。
UDP协议的特点：
UDP是无连接协议；
UDP不能保证可靠的交付数据；
UDP是面向报文传输的；
UDP没有拥塞控制；
UDP首部开销很小。
UDP数据报结构：
首部：8B，四字段/2B【源端口 | 目的端口 | UDP长度 | 校验和】数据字段：应用数据
5.2 TCP协议详解
TCP(Transmission Control Protocol: 传输控制协议)，是计算机网络中非常复杂的一个协议。
TCP协议的功能：
对应用层报文进行分段和重组；
面向应用层实现复用与分解；
实现端到端的流量控制；
拥塞控制；
传输层寻址；
对收到的报文进行差错检测(首部和数据部分都检错)；
实现进程间的端到端可靠数据传输控制。
TCP协议的特点：
TCP是面向连接的协议；
TCP是面向字节流的协议；
TCP的一个连接有两端，即点对点通信；
TCP提供可靠的传输服务；
TCP协议提供全双工通信(每条TCP连接只能一对一)；
5.2.1 TCP报文段结构：
最大报文段长度：报文段中封装的应用层数据的最大长度。
TCP首部：
序号字段：TCP的序号是对每个应用层数据的每个字节进行编号
确认序号字段：期望从对方接收数据的字节序号，即该序号对应的字节尚未收到。用ack_seq标识；
TCP段的首部长度最短是20B ，最长为60字节。但是长度必须为4B的整数倍
TCP标记的作用：
5.3 可靠传输的基本原理
基本原理：不可靠传输信道在数据传输中可能发生的情况：比特差错、乱序、重传、丢失。
基于不可靠信道实现可靠数据传输采取的措施：
差错检测：利用编码实现数据包传输过程中的比特差错检测确认：接收方向发送方反馈接收状态重传：发送方重新发送接收方没有正确接收的数据序号：确保数据按序提交计时器：解决数据丢失问题；
停止等待协议：是最简单的可靠传输协议，但是该协议对信道的利用率不高。
连续ARQ(Automatic Repeat reQuest：自动重传请求)协议：滑动窗口+累计确认，大幅提高了信道的利用率。
5.3.1TCP协议的可靠传输
基于连续ARQ协议，在某些情况下，重传的效率并不高，会重复传输部分已经成功接收的字节。
5.3.2 TCP协议的流量控制
流量控制：让发送方发送速率不要太快，TCP协议使用滑动窗口实现流量控制。
5.4 TCP协议的拥塞控制
拥塞控制与流量控制的区别：流量控制考虑点对点的通信量的控制，而拥塞控制考虑整个网络，是全局性的考虑。拥塞控制的方法：慢启动算法+拥塞避免算法。
慢开始和拥塞避免：
【慢开始】拥塞窗口从1指数增长；
到达阈值时进入【拥塞避免】，变成+1增长；
【超时】，阈值变为当前cwnd的一半(不能<2)；
再从【慢开始】，拥塞窗口从1指数增长。
快重传和快恢复：
发送方连续收到3个冗余ACK，执行【快重传】，不必等计时器超时；
执行【快恢复】，阈值变为当前cwnd的一半(不能<2)，并从此新的ssthresh点进入【拥塞避免】。
5.5 TCP连接的三次握手(重要)
TCP三次握手使用指令：
面试常客：为什么需要三次握手？
第一次握手：客户发送请求，此时服务器知道客户能发；
第二次握手：服务器发送确认，此时客户知道服务器能发能收；
第三次握手：客户发送确认，此时服务器知道客户能收。
建立连接(三次握手)：
第一次：客户向服务器发送连接请求段，建立连接请求控制段(SYN=1)，表示传输的报文段的第一个数据字节的序列号是x，此序列号代表整个报文段的序号(seq=x)；客户端进入 SYN_SEND (同步发送状态)；
第二次：服务器发回确认报文段，同意建立新连接的确认段(SYN=1)，确认序号字段有效(ACK=1)，服务器告诉客户端报文段序号是y(seq=y)，表示服务器已经收到客户端序号为x的报文段，准备接受客户端序列号为x+1的报文段(ack_seq=x+1)；服务器由LISTEN进入SYN_RCVD (同步收到状态);
第三次:客户对服务器的同一连接进行确认.确认序号字段有效(ACK=1),客户此次的报文段的序列号是x+1(seq=x+1),客户期望接受服务器序列号为y+1的报文段(ack_seq=y+1);当客户发送ack时，客户端进入ESTABLISHED 状态;当服务收到客户发送的ack后，也进入ESTABLISHED状态;第三次握手可携带数据;
5.6 TCP连接的四次挥手(重要)
释放连接(四次挥手)
第一次：客户向服务器发送释放连接报文段，发送端数据发送完毕，请求释放连接(FIN=1)，传输的第一个数据字节的序号是x(seq=x)；客户端状态由ESTABLISHED进入FIN_WAIT_1(终止等待1状态)；
第二次：服务器向客户发送确认段，确认字号段有效(ACK=1)，服务器传输的数据序号是y(seq=y)，服务器期望接收客户数据序号为x+1(ack_seq=x+1);服务器状态由ESTABLISHED进入CLOSE_WAIT(关闭等待)；客户端收到ACK段后，由FIN_WAIT_1进入FIN_WAIT_2；
第三次:服务器向客户发送释放连接报文段，请求释放连接(FIN=1)，确认字号段有效(ACK=1)，表示服务器期望接收客户数据序号为x+1(ack_seq=x+1);表示自己传输的第一个字节序号是y+1(seq=y+1)；服务器状态由CLOSE_WAIT 进入 LAST_ACK (最后确认状态)；
第四次：客户向服务器发送确认段，确认字号段有效(ACK=1)，表示客户传输的数据序号是x+1(seq=x+1)，表示客户期望接收服务器数据序号为y+1+1(ack_seq=y+1+1)；客户端状态由FIN_WAIT_2进入TIME_WAIT，等待2MSL时间，进入CLOSED状态；服务器在收到最后一次ACK后，由LAST_ACK进入CLOSED；
为什么需要等待2MSL?
最后一个报文没有确认；
确保发送方的ACK可以到达接收方；
2MSL时间内没有收到，则接收方会重发；
确保当前连接的所有报文都已经过期。
六、应用层
为操作系统或网络应用程序提供访问网络服务的接口。应用层重点：
数据传输基本单位为报文；
包含的主要协议：FTP(文件传送协议)、Telnet(远程登录协议)、DNS(域名解析协议)、SMTP(邮件传送协议)，POP3协议(邮局协议)，HTTP协议(Hyper Text Transfer Protocol)。
6.1 DNS详解
DNS(Domain Name System:域名系统)【C/S，UDP，端口53】：解决IP地址复杂难以记忆的问题,存储并完成自己所管辖范围内主机的 域名 到 IP 地址的映射。
域名解析的顺序：
【1】浏览器缓存，
【2】找本机的hosts文件，
【3】路由缓存，
【4】找DNS服务器(本地域名、顶级域名、根域名)->迭代解析、递归查询。
IP—>DNS服务—>便于记忆的域名
域名由点、字母和数字组成，分为顶级域(com，cn，net，gov，org)、二级域(baidu,taobao,qq,alibaba)、三级域(www)。
6.2 DHCP协议详解
DHCP(Dynamic Configuration Protocol:动态主机设置协议)：是一个局域网协议，是应用UDP协议的应用层协议。作用：为临时接入局域网的用户自动分配IP地址。
6.3 HTTP协议详解
文件传输协议(FTP)：控制连接(端口21)：传输控制信息(连接、传输请求)，以7位ASCII码的格式。整个会话期间一直打开。
HTTP(HyperText Transfer Protocol:超文本传输协议)【TCP，端口80】：是可靠的数据传输协议，浏览器向服务器发收报文前，先建立TCP连接，HTTP使用TCP连接方式(HTTP自身无连接)。
HTTP请求报文方式：
GET：请求指定的页面信息，并返回实体主体；
POST：向指定资源提交数据进行处理请求；
DELETE：请求服务器删除指定的页面；
HEAD：请求读取URL标识的信息的首部，只返回报文头；
OPETION：请求一些选项的信息；
PUT：在指明的URL下存储一个文档。
6.3.1 HTTP工作的结构
6.3.2 HTTPS协议详解
HTTPS(Secure)是安全的HTTP协议，端口号443。基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护。
免责声明：部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有。
七、TCP 和 UDP 是否可以同时监听绑定同一端口
问：TCP 和 UDP 可以同时监听相同的端口吗？
关于端口的知识点，还是挺多可以讲的，比如还可以牵扯到这几个问题：
多个 TCP 服务进程可以同时绑定同一个端口吗？
客户端的端口可以重复使用吗？
客户端 TCP 连接 TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗？
在此跟大家梳理一下这些问题。
TCP 和 UDP 可以同时绑定相同的端口吗？
「监听」这个动作是在 TCP 服务端网络编程中才具有的，而 UDP 服务端网络编程中是没有「监听」这个动作的。TCP 和 UDP 服务端网络相似的一个地方，就是会调用 bind 绑定端口，可以看一下TCP 和 UDP 网络编程的区别。
TCP 网络编程如下，服务端执行 listen() 系统调用就是监听端口的动作。
TCP 网络编程
UDP 网络编程如下，服务端是没有监听这个动作的，只有执行 bind() 系统调用来绑定端口的动作。
UDP 网络编程
TCP 和 UDP 可以同时绑定相同的端口吗？
答案：可以的。
在数据链路层中，通过 MAC 地址来寻找局域网中的主机。在网际层中，通过 IP 地址来寻找网络中互连的主机或路由器。在传输层中，需要通过端口进行寻址，来识别同一计算机中同时通信的不同应用程序。
所以传输层的「端口号」的作用，是为了区分同一个主机上不同应用程序的数据包。传输层有两个传输协议分别是 TCP 和 UDP，在内核中是两个完全独立的软件模块。
当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。
因此TCP/UDP 各自的端口号也相互独立，如 TCP 有一个 80 号端口，UDP 也可以有一个 80 号端口，二者并不冲突。
多个 TCP 服务进程可以绑定同一个端口吗？
还是以前面的 TCP 服务端程序作为例子，启动两个同时绑定同一个端口的 TCP 服务进程。
运行第一个 TCP 服务进程之后，netstat 命令可以查看，8888 端口已经被一个 TCP 服务进程绑定并监听了；运行第二个 TCP 服务进程的时候，就报错了“Address already in use”。
测试案例是两个 TCP 服务进程同时绑定地址和端口是：0.0.0.0 地址和8888端口，所以才出现的错误。如果两个 TCP 服务进程绑定的 IP 地址不同，而端口相同的话，也是可以绑定成功的。
所以在默认情况下，针对「多个 TCP 服务进程可以绑定同一个端口吗？」这个问题的答案是：如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同，那么执行 bind() 时候就会出错，错误是“Address already in use”。
注意，如果 TCP 服务进程 A 绑定的地址是 0.0.0.0 和端口 8888，而如果 TCP 服务进程 B 绑定的地址是 192.168.1.100 地址（或者其他地址）和端口 8888，那么执行 bind() 时候也会出错。因为 0.0.0.0 地址比较特殊，代表任意地址，意味着绑定了 0.0.0.0 地址，相当于把主机上的所有 IP 地址都绑定了。
重启 TCP 服务进程时，为什么会有“Address in use”的报错信息？
TCP 服务进程需要绑定一个 IP 地址和一个端口，然后就监听在这个地址和端口上，等待客户端连接的到来。在实践中可能会经常碰到一个问题，当 TCP 服务进程重启之后，总是碰到“Address in use”的报错信息，TCP 服务进程不能很快地重启，而是要过一会才能重启成功。
这是为什么呢？
当我们重启 TCP 服务进程的时候，意味着通过服务器端发起了关闭连接操作，于是就会经过四次挥手，而对于主动关闭方，会在 TIME_WAIT 这个状态里停留一段时间，这个时间大约为 2MSL。
当 TCP 服务进程重启时，服务端会出现 TIME_WAIT 状态的连接，TIME_WAIT 状态的连接使用的 IP+PORT 仍然被认为是一个有效的 IP+PORT 组合，相同机器上不能够在该 IP+PORT 组合上进行绑定，那么执行 bind() 函数的时候，就会返回了 Address already in use 的错误。
而等 TIME_WAIT 状态的连接结束后，重启 TCP 服务进程就能成功。
重启 TCP 服务进程时，如何避免“Address in use”的报错信息？
可以在调用 bind 前，对 socket 设置 SO_REUSEADDR 属性，可以解决这个问题。
int on = 1; setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
因为 SO_REUSEADDR 作用是：如果当前启动进程绑定的 IP+PORT 与处于TIME_WAIT 状态的连接占用的 IP+PORT 存在冲突，但是新启动的进程使用了 SO_REUSEADDR 选项，那么该进程就可以绑定成功。
举例，服务端有个监听 0.0.0.0 地址和 8888 端口的 TCP 服务进程。有个客户端（IP地址：192.168.1.100）已经和服务端（IP 地址：172.19.11.200）建立了 TCP 连接，那么在 TCP 服务进程重启时，服务端会与客户端经历四次挥手，服务端的 TCP 连接会短暂处于 TIME_WAIT 状态：
客户端地址:端口 服务端地址:端口 TCP 连接状态 192.168.1.100:37272 172.19.11.200:8888 TIME_WAIT
如果 TCP 服务进程没有对 socket 设置 SO_REUSEADDR 属性，那么在重启时，由于存在一个和绑定 IP+PORT 一样的 TIME_WAIT 状态的连接，那么在执行 bind() 函数的时候，就会返回了 Address already in use 的错误。
如果 TCP 服务进程对 socket 设置 SO_REUSEADDR 属性了，那么在重启时，即使存在一个和绑定 IP+PORT一样的 TIME_WAIT 状态的连接，依然可以正常绑定成功，因此可以正常重启成功。
因此在所有 TCP 服务器程序中，调用 bind 之前最好对 socket 设置 SO_REUSEADDR 属性，这不会产生危害，相反它会帮助我们在很快时间内重启服务端程序。
前面我提到过这个问题：如果 TCP 服务进程 A 绑定的地址是 0.0.0.0 和端口 8888，而如果 TCP 服务进程 B 绑定的地址是 192.168.1.100 地址（或者其他地址）和端口 8888，那么执行 bind() 时候也会出错。
该问题也可以由 SO_REUSEADDR 解决，因为它的另外一个作用是：绑定的 IP地址 + 端口时，只要 IP 地址不是正好(exactly)相同，那么允许绑定。
比如，0.0.0.0:8888 和192.168.1.100:8888，虽然逻辑意义上前者包含了后者，但是 0.0.0.0 泛指所有本地 IP，而 192.168.0.100 特指某一IP，两者并不是完全相同，所以在对 socket 设置 SO_REUSEADDR 属性后，那么执行 bind() 时候就会绑定成功。
客户端的端口可以重复使用吗？
客户端在执行 connect 函数的时候，会在内核里随机选择一个端口，然后向服务端发起 SYN 报文，然后与服务端进行三次握手。
所以客户端的端口选择发生在 connect 函数，内核在选择端口的时候，会从 net.ipv4.ip_local_port_range 这个内核参数指定的范围来选取一个端口作为客户端端口。
该参数的默认值是 32768 61000，意味着端口总可用的数量是 61000 - 32768 = 28232 个。
当客户端与服务端完成 TCP 连接建立后，我们可以通过 netstat 命令查看 TCP 连接。
$ netstat -napt
协议 源ip地址:端口 目的ip地址：端口 状态
tcp 192.168.110.182.64992 117.147.199.51.443 ESTABLISHED
那问题来了，上面客户端已经用了 64992 端口，那么还可以继续使用该端口发起连接吗？
这个问题，很多同学都会说不可以继续使用该端口了，如果按这个理解的话， 默认情况下客户端可以选择的端口是 28232 个，那么意味着客户端只能最多建立 28232 个 TCP 连接，如果真是这样的话，那么这个客户端并发连接也太少了吧，所以这是错误理解。
正确的理解是，TCP 连接是由四元组（源IP地址，源端口，目的IP地址，目的端口）唯一确认的，那么只要四元组中其中一个元素发生了变化，那么就表示不同的 TCP 连接的。所以如果客户端已使用端口 64992 与服务端 A 建立了连接，那么客户端要与服务端 B 建立连接，还是可以使用端口 64992 的，因为内核是通过四元祖信息来定位一个 TCP 连接的，并不会因为客户端的端口号相同，而导致连接冲突的问题。
多个客户端可以 bind 同一个端口吗？
bind 函数虽然常用于服务端网络编程中，但是它也适用于客户端的。
前面我们知道，客户端是在调用 connect 函数的时候，由内核随机选取一个端口作为连接的端口。而如果想自己指定连接的端口，就可以用 bind 函数来实现：客户端先通过 bind 函数绑定一个端口，然后调用 connect 函数就会跳过端口选择的过程了，转而使用 bind 时确定的端口。
针对这个问题：多个客户端可以 bind 同一个端口吗？
要看多个客户端绑定的 IP + PORT 是否都相同，如果都是相同的，那么在执行 bind() 时候就会出错，错误是“Address already in use”。
如果一个绑定在 192.168.1.100:6666，一个绑定在 192.168.1.200:6666，因为 IP 不相同，所以执行 bind() 的时候，能正常绑定。所以如果多个客户端同时绑定的 IP 地址和端口都是相同的，那么执行 bind() 时候就会出错，错误是“Address already in use”。
一般而言，客户端不建议使用 bind 函数，应该交由 connect 函数来选择端口会比较好，因为客户端的端口通常都没什么意义。
客户端 TCP 连接 TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗？
针对这个问题要看，客户端是否都是与同一个服务器（目标地址和目标端口一样）建立连接。如果客户端都是与同一个服务器（目标地址和目标端口一样）建立连接，那么如果客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。
但因为只要客户端连接的服务器不同，端口资源可以重复使用的。所以如果客户端都是与不同的服务器建立连接，即使客户端端口资源只有几万个， 客户端发起百万级连接也是没问题的（当然这个过程还会受限于其他资源，比如文件描述符、内存、CPU 等）。
如何解决客户端 TCP 连接 TIME_WAIT 过多，导致无法与同一个服务器建立连接的问题？
前面我们提到，如果客户端都是与同一个服务器（目标地址和目标端口一样）建立连接，那么如果客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。
针对这个问题，也是有解决办法的，那就是打开 net.ipv4.tcp_tw_reuse 这个内核参数。
因为开启了这个内核参数后，客户端调用 connect 函数时，如果选择到的端口，已经被相同四元组的连接占用的时候，就会判断该连接是否处于 TIME_WAIT 状态，如果该连接处于 TIME_WAIT 状态并且 TIME_WAIT 状态持续的时间超过了 1 秒，那么就会重用这个连接，然后就可以正常使用该端口了。
举个例子，假设客户端已经与服务器建立了一个 TCP 连接，并且这个状态处于 TIME_WAIT 状态：
客户端地址:端口 服务端地址:端口 TCP 连接状态
192.168.1.100:2222 172.19.11.21:8888 TIME_WAIT
然后客户端又与该服务器（172.19.11.21:8888）发起了连接，在调用 connect 函数时，内核刚好选择了 2222 端口，接着发现已经被相同四元组的连接占用了：
如果没有开启net.ipv4.tcp_tw_reuse 内核参数，那么内核就会选择下一个端口，然后继续判断，直到找到一个没有被相同四元组的连接使用的端口，如果端口资源耗尽还是没找到，那么 connect 函数就会返回错误。
如果开启了 net.ipv4.tcp_tw_reuse 内核参数，就会判断该四元组的连接状态是否处于 TIME_WAIT 状态，如果连接处于 TIME_WAIT 状态并且该状态持续的时间超过了 1 秒，那么就会重用该连接，于是就可以使用 2222 端口了，这时 connect 就会返回成功。
再次提醒一次，开启了 net.ipv4.tcp_tw_reuse 内核参数，是客户端（连接发起方） 在调用 connect() 函数时才起作用，所以在服务端开启这个参数是没有效果的。
客户端端口选择的流程总结
至此已经把客户端在执行 connect 函数时，内核选择端口的情况大致说了一遍，为了让大家更明白客户端端口的选择过程准备了一张流程图：
小结
TCP 和 UDP 可以同时绑定相同的端口。TCP 和 UDP 传输协议，在内核中是由两个完全独立的软件模块实现的。当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。因此TCP/UDP各自的端口号也相互独立，互不影响。
多个 TCP 服务进程可以同时绑定同一个端口吗？
如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同，那么执行 bind() 时候就会出错，错误是“Address already in use”。如果两个 TCP 服务进程绑定的端口都相同，而 IP 地址不同，那么执行 bind() 不会出错。
如何解决服务端重启时，报错“Address already in use”的问题？
当重启 TCP 服务进程的时候，意味着通过服务器端发起了关闭连接操作，于是就会经过四次挥手，而对于主动关闭方，会在 TIME_WAIT 这个状态里停留一段时间，这个时间大约为 2MSL。当 TCP 服务进程重启时，服务端会出现 TIME_WAIT 状态的连接，TIME_WAIT 状态的连接使用的 IP+PORT 仍然被认为是一个有效的 IP+PORT 组合，相同机器上不能够在该 IP+PORT 组合上进行绑定，那么执行 bind() 函数的时候，就会返回了 Address already in use 的错误。要解决这个问题可以对 socket 设置 SO_REUSEADDR 属性。这样即使存在一个和绑定 IP+PORT一样的 TIME_WAIT 状态的连接，依然可以正常绑定成功，因此可以正常重启成功。
客户端的端口可以重复使用吗？
在客户端执行 connect 函数的时候，只要客户端连接的服务器不是同一个内核，允许端口重复使用。TCP 连接是由四元组（源IP地址，源端口，目的IP地址，目的端口）唯一确认的，那么只要四元组中其中一个元素发生了变化，那么就表示不同的 TCP 连接的。所以，如果客户端已使用端口 64992 与服务端 A 建立了连接，那么客户端要与服务端 B 建立连接，还是可以使用端口 64992 的，因为内核是通过四元祖信息来定位一个 TCP 连接的，并不会因为客户端的端口号相同，而导致连接冲突的问题。
客户端 TCP 连接 TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗？
要看客户端是否都是与同一个服务器（目标地址和目标端口一样）建立连接。如果客户端都是与同一个服务器（目标地址和目标端口一样）建立连接，那么如果客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。即使在这种状态下，还是可以与其他服务器建立连接的，只要客户端连接的服务器不是同一个，那么端口是重复使用的。
如何解决客户端 TCP 连接 TIME_WAIT 过多，导致无法与同一个服务器建立连接的问题？
打开 net.ipv4.tcp_tw_reuse 这个内核参数。因为开启了这个内核参数后，客户端调用 connect 函数时，如果选择到的端口，已经被相同四元组的连接占用的时候，就会判断该连接是否处于 TIME_WAIT 状态。如果该连接处于 TIME_WAIT 状态并且 TIME_WAIT 状态持续的时间超过了 1 秒，那么就会重用这个连接，然后就可以正常使用该端口了。
参考：端口基础常识大全
一、计算机网络概述
1.1 计算机网络的分类
按照网络的作用范围：广域网(WAN)、城域网(MAN)、局域网(LAN)；
按照网络使用者：公用网络、专用网络。
1.2 计算机网络的层次结构
TCP/IP四层模型与OSI体系结构对比：
1.3 层次结构设计的基本原则
各层之间是相互独立的；
每一层需要有足够的灵活性；
各层之间完全解耦。
1.4 计算机网络的性能指标
速率：bps=bit/s，时延：发送时延、传播时延、排队时延、处理时延往返时间，RTT：数据报文在端到端通信中的来回一次的时间。
认识网络速率单位
在电信IDC合同中或交换机流量查看中，所看到的数值，这些究竟是多大呢，如何直观地理解它们呢。
在计算机科学中，bit是表示信息的最小单位，叫做二进制位，一般用0和1表示。Byte叫做字节，由8个位(8bit)组成一个字节(1Byte)，用于表示计算机中的一个字符。bit与Byte之间可以进行换算，其换算关系为：1Byte=8bit(或简写为：1B=8b)；在实际应用中一般用简称，即1bit简写为1b(注意是小写英文字母b)，1Byte简写为1B(注意是大写英文字母B)。
在计算机网络或者是网络运营商中，一般宽带速率的单位用bps(或b/s)表示；bps表示比特每秒即表示每秒钟传输多少位信息，是bit per second的缩写。在实际所说的1M带宽的意思是1Mbps(是兆比特每秒Mbps不是兆字节每秒MBps)。
建议用户记住以下换算公式：
1B=8b 1B/s=8b/s(或1Bps=8bps)
1KB=1024B 1KB/s=1024B/s
1MB=1024KB 1MB/s=1024KB/s
规范提示：实际书写规范中B应表示Byte(字节)，b应表示bit(比特)，但在平时的实际书写中有的把bit和Byte都混写为b，如把Mb/s和MB/s都混写为Mb/s，导致人们在实际计算中因单位的混淆而出错。
实例：在我们实际上网应用中，下载软件时常常看到诸如下载速度显示为128KBps(KB/s)，103KB/s等等宽带速率大小字样，因为ISP提供的线路带宽使用的单位是比特，而一般下载软件显示的是字节(1字节＝8比特)，所以要通过换算，才能得实际值。然而我们可以按照换算公式换算一下：
128KB/s=128×8(Kb/s)=1024Kb/s=1Mb/s 即 128KB/s=1Mb/s。
所谓1M带宽，其实是指1Mbps(每秒百万位元)线路速度，而其下载速度计算方式是1x1024/8=128KB/sec(每秒128位元组)，但这只是理论上的速度，因为在实际应用上，还要再减去一定的网络速率的损耗。
据TMnet Streamyx官方网站披露，除了以太网络标头值(Ethernet Header)之外，这些流失因素包括传输控制协议标头值(TCP Header)有5至10％的传输控制消耗，而异步传输模式标头值(ATM Header)则多达15％。 因此：1M宽带的实际上网速度是1乘以1024和除去8，得出128KB/s再乘75％，等于96KB/s，就是你的1M宽带网络的真正数据传输速率。
目前我国宽带上网速度介于512Kbps至2Mbps之间。同样的道理，在2M或512K也是一样，512K则是512Kbps(每秒千位元)。以此计算的话，我们可以粗略得出目前宽频的实际下载速度：
宽频线路速度 理想下载速度 实际下载速度
2Mbps 256KB/s 192KB/s
1Mbps 128KB/s 96KB/s
512Kbps 64KB/s 48KB/s
一般说来，带宽越大，下载速度就越快，但下载速度除受服务供应商因素所影响外，用户本身所使用操作系统、浏览器及电脑配备等因素，亦可影响宽频速度，其中又以最大传输单位(Maximum Transmission Unit，MTU)设定错误问题最为常见。
1Mbps是多少兆？
1Mbps=1024Kbps=1024/8KBps=128KB/s
1M的宽带最高下载速度可以达到128K/s，但是这只是最高极限速度，考虑一些其它因素如链路的质量、计算机或接收软件的处理能力及传输过程中的开销。假如是10M宽带，10M=10240Kbps=1280KB/s，这个1280kb/s就是最大的下载网速。所以1Mbps就是1兆，在电脑中，1M的宽带在下载文件时，平均下载速率就是100KB/s。
每秒千位元或百万位元：Mbps其实是指每秒百万位元(Megabits per second)，而Kbps则是每秒千位元(Kilobits per second)。
也许你会问：“位元又是什么？”其实，电脑是以bit(位元)和Byte(位元组)作为计算单位。bit是“binary digit”的缩写，它是电脑辨识讯息的最小单位，再上一个更大的单位为位元组(byte)。由于八个位元一组(8 bits = 1 byte)，我们常在电脑打的每一个字体或符号等资料，通常会以位元组的方式来打包。一个位元组代表示一个字符，例如“Q”、“4”或“，”等，都属于一个位元组。
正如长度计算单位的公尺(Meter，M)和公里(Kilometer，KM)的情况一样，电脑将位元组的一千倍称作KB(Kilobyte)，而KB的一千倍为MB(Megabyte)。
当然，一千倍是笼统的说法。由于电脑使用的是二进位系统，准确的倍数计算法是二的十次方，因此1KB相等于1024个位元组。
KB和Kb大小写意义不同
一般用来上网的数据机及网络通讯的传输速率都是以“bps”为单位，例如14.4Kbps，28.8Kbps，56Kbps，1Mbps及2Mbps等等。无论用作电脑储存或网络速度的计算单位，Kb/s和KB/s英文字母大写和小写之意义截然不同，这是许多人常会犯错的地方。
大写的B代表位元组(Byte)，小写的b则代表位元(bit)，所以MB(Megabyte)是百万位元组，Mb(megabit)是百万位元；KB/s是每秒千位元组，而Kbps则是每秒千位元。
网络速度单位之间关系：
●Kb/s＝每秒千位元，用于线路速度。
●KB/s＝每秒千位元组，用于下载速度。
●1KB/s = 8Kb/s
●1 Byte(位元组) = 8 bits(位元)
●1 Kb(千位元) = 1024 bit(位元)s
●1 KB(千位元组) = 1024 bytes(位元组)
●1 Mb (百万位元)= 1024 Kb(位元)
●1 MB(百万位元组) = 1024 KB(位元组)
MB和Mb、MB/s和Mb/s是有区别的。
其中大B代表Byte(字节)，小b代表bit(比特或位)。
1 Kb = 1024 bit
1 KB = 1024 Byte
1 Mb = 1024 Kb
1 MB = 1024 KB
1 Byte = 8 bit
1 MB = 8Mb
1 Mb = 0.125 MB
数据传输率的单位一般采用MB/s或Mb/s。在数据传输率上官方数据中(如电信部门)一般采用Mb/s为单位，而下载软件(如IE、迅雷、快车)一般采用MB、KB/s为单位。
宽带最高下载理论值：
1Mb/s = 0.125MB/s = 128KB/s
电信部门说的1M宽带的M是指Mb/s，下载软件时的传输率是MB/S，也就是1M宽带下载速度最快128KB/s，再去掉损耗也就是120KB/s左右。按这个说法10M的宽带最快下载速度是1.25MB/s，100M的局域网宽带最快下载速度是12.5MB/s。
MB/s的含义是兆字节每秒，Mb/s的含义是兆比特每秒，前者是指每秒传输的字节数量，后者是指每秒传输的比特位数，二者是完全不同的。Byte是字节数，bit是位数，在计算机中每八位为一字节，也就是1Byte＝8bit，是1：8的对应关系，因此1MB/s等于8Mb/s。因此在在书写单位时一定要注意B字母的大小写，此时B字母的大小真可以称为失之毫厘，谬以千里。
网络技术中的 10M 带宽指的是以位计算，就是 10Mbit/秒，而下载时的速度看到的是以字节(Byte)计算的，所以 10M 带宽换算成字节理论上最快下载速度为: 1.25 MByte/秒
在计算机/通讯行业中，计算数据传送速度也使用十进制来衡量。
在数据存储容量计算中，一般采用二进制来衡量。1MB=1024K=1024*1024B。
根据进制规定，传送速度可以有两种表示方法 bps和Bps，但是他们是有严格区别。Bps中的B使用的是二进制系统中的Byte字节，bps中的b是十进制系统中的位元。在我们常说的56K拨号，100M局域网都是bps计量，当用于软件下在时，下载工具一般又以Bps计算，所以它们之间有8bit=1Byte的换算关系。
MB和MiB的区别
MB：单位以10为底数的指数：
1KB=10^3 =1000,
1MB=10^6=1000000=1000KB
1GB=10^9=1000000000=1000MB
MiB：是以2为底数的指数：
1KiB=2^10=1024,
1MiB=2^20=1048576=1024KiB
1GiB=2^30=1,073,741,824=1024MiB
在计算机领域以前常说的KB，MB和GB跟KiB，MiB和GiB是完全一样的。KiB，MiB和GiB这三个标志是标准的计算机领域的术语，中间的i取自binary，表示二进制幂的计数：
1KiB = 1024 Byte
1MiB = 1024 KiB = 1048576 Byte
1GiB = 1024 MiB
1TiB = 1024 GiB
1999年，国际电工委员会（IEC）公布了修正2：“IEC 60027-2：电工技术应用的字母符号 -- 第二部分：通信和电子。”
该标准在1998年通过，介绍了词头“kibi-”、“mebi-”、“gibi-”、“tebi-”、“pebi-”、“exbi-”，作为二进制乘幂的计数方法。要读懂这段规定，其内涵是定义了符号的规范用法。Mi、Ki、Gi代表的是二进制乘幂的计数方法。反过来讲，就是规范了一个标准，只要出现上述标志的，意味着这种使用是规范的。而我们日常使用的MB、KB等用法存在着很多歧义。这种硬性规定是出于学术上的考虑的。在实际使用中，MB的意义和MiB应该是等同的。
不过在通信领域的日常口语中，KB，MB和GB就不一定是二进制幂的表示。K就是1000，M就是1000*1000。
还要注意一个细节，一般B大写指Byte，b小写指bit。在计算机领域，B一般都是大写的。
使用iperf检查带宽
吉比特以太网理论上的限制是 128MBit/s。这个数字从何而来，看看这些计算：
1Gb = 1024Mb；1024Mb/8 = 128MB；'b' = 'bits'、'B' = 'bytes'
但实际看到的是什么呢，有什么好的测量方法呢？推荐一个工具 iperf。需要在两台机器上均安装此工具，或者在两个节点上编译并安装。我将在两个节点的 freeoa 用户的主目录中编译它：
tar zxvf iperf-2.0.2.tar.gz
cd iperf-2.0.2
./configure --prefix=/home/freeoa/iperf
make
make install
在一台机器上运行：
# /home/freeoa/iperf/bin/iperf -s -f M
这台机器将用作服务器并以 MBit/s 为单位输出执行速度。
在另外一台节点上，运行：
# /home/freeoa/perf/bin/iperf -c the-mac-name -P 4 -f M -w 256k -t 60
两个屏幕上的结果都指示了速度是多少。在使用吉比特适配器的普通服务器上，可能会看到速度约为 112MBit/s。这是 TCP 堆栈和物理电缆中的常用带宽。通过以端到端的方式连接两台服务器，每台服务器使用两个独立的以太网卡，获得了约 220MBit/s 的带宽。事实上，在内部网络上看到的 NFS 约为 150-160MBit/s，这仍然表示带宽可以达到预期效果。如果看到更小的值，则应该检查是否有问题。
二、物理层
物理层的作用：连接不同的物理设备，传输比特流。该层为上层协议提供了一个传输数据的可靠的物理媒体。简单的说，物理层确保原始的数据可在各种物理媒体上传输。
物理层设备：
中继器【Repeater，也叫放大器】：同一局域网的再生信号；两端口的网段必须同一协议；5-4-3规程：10BASE-5以太网中，最多串联4个中继器，5段中只能有3个连接主机；
集线器：同一局域网的再生、放大信号(多端口的中继器)；半双工，不能隔离冲突域也不能隔离广播域。
信道的基本概念：信道是往一个方向传输信息的媒体，一条通信电路包含一个发送信道和一个接受信道。
单工通信信道：只能一个方向通信，没有反方向反馈的信道；
半双工通信信道：双方都可以发送和接受信息，但不能同时发送也不能同时接收；
全双工通信信道：双方都可以同时发送和接收。
三、数据链路层
3.1 数据链路层概述
数据链路层在物理层提供的服务的基础上向网络层提供服务，其最基本的服务是将源自网络层来的数据可靠地传输到相邻节点的目标机网络层。数据链路层在不可靠的物理介质上提供可靠的传输。
该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
有关数据链路层的重要知识点：
数据链路层为网络层提供可靠的数据传输；
基本数据单位为帧；
主要的协议：以太网协议；
两个重要设备名称：网桥和交换机。
封装成帧：“帧”是数据链路层数据的基本单位：
透明传输：“透明”是指即使控制字符在帧数据中，但是要当做不存在去处理。即在控制字符前加上转义字符ESC。
3.2 数据链路层的差错监测
差错检测：奇偶校验码、循环冗余校验码CRC
奇偶校验码–局限性：当出错两位时，检测不到错误。
循环冗余检验码：根据传输或保存的数据而产生固定位数校验码。
3.3 最大传输单元MTU
最大传输单元MTU(Maximum Transmission Unit)，数据链路层的数据帧不是无限大的，数据帧长度受MTU限制.
路径MTU：由链路中MTU的最小值决定。
3.4 以太网协议详解
MAC地址：每一个设备都拥有唯一的MAC地址，共48位，使用十六进制表示。
以太网协议：是一种使用广泛的局域网技术，是一种应用于数据链路层的协议，使用以太网可以完成相邻设备的数据帧传输：
局域网分类：
Ethernet以太网IEEE802.3：
以太网第一个广泛部署的高速局域网
以太网数据速率快
以太网硬件价格便宜，网络造价成本低
以太网帧结构：
类型：标识上层协议(2字节)
目的地址和源地址：MAC地址(每个6字节)
数据：封装的上层协议的分组(46~1500字节)
CRC：循环冗余码(4字节)
以太网最短帧：以太网帧最短64字节；以太网帧除了数据部分18字节；数据最短46字节；
MAC地址(物理地址、局域网地址)
MAC地址长度为6字节，48位；
MAC地址具有唯一性，每个网络适配器对应一个MAC地址；
通常采用十六进制表示法，每个字节表示一个十六进制数，用 - 或 : 连接起来；
MAC广播地址：FF-FF-FF-FF-FF-FF。
四、网络层
网络层的目的是实现两个端系统之间的数据透明传送，具体功能包括寻址和路由选择、连接的建立、保持和终止等。数据交换技术是报文交换(基本上被分组所替代)：采用储存转发方式，数据交换单位是报文。
网络层中涉及众多的协议，其中包括最重要的协议，也是TCP/IP的核心协议——IP协议。IP协议非常简单，仅仅提供不可靠、无连接的传送服务。IP协议的主要功能有：无连接数据报传输、数据报路由选择和差错控制。
与IP协议配套使用实现其功能的还有地址解析协议ARP、逆地址解析协议RARP、因特网报文协议ICMP、因特网组管理协议IGMP。具体的协议我们会在接下来的部分进行总结，有关网络层的重点为：
网络层负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能；
基本数据单位为IP数据报；
包含的主要协议：
IP协议(Internet Protocol，因特网互联协议);
ICMP协议(Internet Control Message Protocol，因特网控制报文协议);
ARP协议(Address Resolution Protocol，地址解析协议);
RARP协议(Reverse Address Resolution Protocol，逆地址解析协议)。
重要的设备：路由器。
路由器相关协议
4.1 IP协议详解
IP网际协议是 Internet 网络层最核心的协议。虚拟互联网络的产生：实际的计算机网络错综复杂；物理设备通过使用IP协议，屏蔽了物理网络之间的差异；当网络中主机使用IP协议连接时，无需关注网络细节，于是形成了虚拟网络。
IP协议使得复杂的实际网络变为一个虚拟互联的网络；并且解决了在虚拟网络中数据报传输路径的问题。
其中，版本指IP协议的版本，占4位，如IPv4和IPv6；首部位长度表示IP首部长度，占4位，最大数值位15；总长度表示IP数据报总长度，占16位，最大数值位65535；TTL表示IP数据报文在网络中的寿命，占8位；协议表明IP数据所携带的具体数据是什么协议的，如TCP、UDP。
4.2 IP协议的转发流程
4.3 IP地址的子网划分
A类(8网络号+24主机号)、B类(16网络号+16主机号)、C类(24网络号+8主机号)可以用于标识网络中的主机或路由器，D类地址作为组广播地址，E类是地址保留。
4.4 网络地址转换NAT技术
用于多个主机通过一个公有IP访问访问互联网的私有网络中，减缓了IP地址的消耗，但是增加了网络通信的复杂度。
NAT 工作原理：
从内网出去的IP数据报，将其IP地址替换为NAT服务器拥有的合法的公共IP地址，并将替换关系记录到NAT转换表中；
从公共互联网返回的IP数据报，依据其目的的IP地址检索NAT转换表，并利用检索到的内部私有IP地址替换目的IP地址，然后将IP数据报转发到内部网络。
4.5 ARP协议与RARP协议
地址解析协议 ARP(Address Resolution Protocol)：为网卡(网络适配器)的IP地址到对应的硬件地址提供动态映射。可以把网络层32位地址转化为数据链路层MAC48位地址。
ARP 是即插即用的，一个ARP表是自动建立的，不需要系统管理员来配置。
RARP(Reverse Address Resolution Protocol)协议指逆地址解析协议，可以把数据链路层MAC48位地址转化为网络层32位地址。
4.6 ICMP协议详解
网际控制报文协议(Internet Control Message Protocol)，可以报告错误信息或者异常情况，ICMP报文封装在IP数据报当中。
ICMP协议的应用：
Ping应用：网络故障的排查；
Traceroute应用：可以探测IP数据报在网络中走过的路径。
4.7网络层的路由概述
关于路由算法的要求：正确的完整的、在计算上应该尽可能是简单的、可以适应网络中的变化、稳定的公平的。
自治系统AS：指处于一个管理机构下的网络设备群，AS内部网络自治管理，对外提供一个或多个出入口，其中自治系统内部的路由协议为内部网关协议，如RIP、OSPF等；自治系统外部的路由协议为外部网关协议，如BGP。
静态路由：人工配置，难度和复杂度高；
动态路由：
链路状态路由选择算法LS：向所有隔壁路由发送信息收敛快；全局式路由选择算法，每个路由器计算路由时，需构建整个网络拓扑图；利用Dijkstra算法求源端到目的端网络的最短路径；Dijkstra(迪杰斯特拉)算法
距离-向量路由选择算法DV：向所有隔壁路由发送信息收敛慢、会存在回路；基础是Bellman-Ford方程(简称B-F方程)；
4.8 内部网关路由协议之RIP协议
路由信息协议 RIP(Routing Information Protocol)【应用层】，基于距离-向量的路由选择算法，较小的AS(自治系统)，适合小型网络；RIP报文，封装进UDP数据报。
RIP协议特性：
RIP在度量路径时采用的是跳数(每个路由器维护自身到其他每个路由器的距离记录)；
RIP的费用定义在源路由器和目的子网之间；
RIP被限制的网络直径不超过15跳；
和隔壁交换所有的信息，30主动一次(广播)。
4.9 内部网关路由协议之OSPF协议
开放最短路径优先协议 OSPF(Open Shortest Path First)【网络层】，基于链路状态的路由选择算法(即Dijkstra算法)，较大规模的AS ，适合大型网络，直接封装在IP数据报传输。
OSPF协议优点：
安全；
支持多条相同费用路径；
支持区别化费用度量；
支持单播路由和多播路由；
分层路由。
RIP与OSPF的对比(路由算法决定其性质)：
4.10外部网关路由协议之BGP协议
BGP(Border Gateway Protocol)边际网关协议【应用层】：是运行在AS之间的一种协议,寻找一条好路由：首次交换全部信息，以后只交换变化的部分,BGP封装进TCP报文段.
五、传输层
第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。
传输层的任务是根据通信子网的特性，最佳的利用网络资源，为两个端系统的会话层之间，提供建立、维护和取消传输连接的功能，负责端到端的可靠数据传输。在这一层，信息传送的协议数据单元称为段或报文。
网络层只是根据网络地址将源结点发出的数据包传送到目的结点，而传输层则负责将数据可靠地传送到相应的端口。
有关网络层的重点：
传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制问题；
包含的主要协议：TCP协议(Transmission Control Protocol，传输控制协议)、UDP协议(User Datagram Protocol，用户数据报协议)；
重要设备：网关。
5.1 UDP协议详解
UDP(User Datagram Protocol: 用户数据报协议)，是一个非常简单的协议。
UDP协议的特点：
UDP是无连接协议；
UDP不能保证可靠的交付数据；
UDP是面向报文传输的；
UDP没有拥塞控制；
UDP首部开销很小。
UDP数据报结构：
首部：8B，四字段/2B【源端口 | 目的端口 | UDP长度 | 校验和】数据字段：应用数据
5.2 TCP协议详解
TCP(Transmission Control Protocol: 传输控制协议)，是计算机网络中非常复杂的一个协议。
TCP协议的功能：
对应用层报文进行分段和重组；
面向应用层实现复用与分解；
实现端到端的流量控制；
拥塞控制；
传输层寻址；
对收到的报文进行差错检测(首部和数据部分都检错)；
实现进程间的端到端可靠数据传输控制。
TCP协议的特点：
TCP是面向连接的协议；
TCP是面向字节流的协议；
TCP的一个连接有两端，即点对点通信；
TCP提供可靠的传输服务；
TCP协议提供全双工通信(每条TCP连接只能一对一)；
5.2.1 TCP报文段结构：
最大报文段长度：报文段中封装的应用层数据的最大长度。
TCP首部：
序号字段：TCP的序号是对每个应用层数据的每个字节进行编号
确认序号字段：期望从对方接收数据的字节序号，即该序号对应的字节尚未收到。用ack_seq标识；
TCP段的首部长度最短是20B ，最长为60字节。但是长度必须为4B的整数倍
TCP标记的作用：
5.3 可靠传输的基本原理
基本原理：不可靠传输信道在数据传输中可能发生的情况：比特差错、乱序、重传、丢失。
基于不可靠信道实现可靠数据传输采取的措施：
差错检测：利用编码实现数据包传输过程中的比特差错检测确认：接收方向发送方反馈接收状态重传：发送方重新发送接收方没有正确接收的数据序号：确保数据按序提交计时器：解决数据丢失问题；
停止等待协议：是最简单的可靠传输协议，但是该协议对信道的利用率不高。
连续ARQ(Automatic Repeat reQuest：自动重传请求)协议：滑动窗口+累计确认，大幅提高了信道的利用率。
5.3.1TCP协议的可靠传输
基于连续ARQ协议，在某些情况下，重传的效率并不高，会重复传输部分已经成功接收的字节。
5.3.2 TCP协议的流量控制
流量控制：让发送方发送速率不要太快，TCP协议使用滑动窗口实现流量控制。
5.4 TCP协议的拥塞控制
拥塞控制与流量控制的区别：流量控制考虑点对点的通信量的控制，而拥塞控制考虑整个网络，是全局性的考虑。拥塞控制的方法：慢启动算法+拥塞避免算法。
慢开始和拥塞避免：
【慢开始】拥塞窗口从1指数增长；
到达阈值时进入【拥塞避免】，变成+1增长；
【超时】，阈值变为当前cwnd的一半(不能<2)；
再从【慢开始】，拥塞窗口从1指数增长。
快重传和快恢复：
发送方连续收到3个冗余ACK，执行【快重传】，不必等计时器超时；
执行【快恢复】，阈值变为当前cwnd的一半(不能<2)，并从此新的ssthresh点进入【拥塞避免】。
5.5 TCP连接的三次握手(重要)
TCP三次握手使用指令：
面试常客：为什么需要三次握手？
第一次握手：客户发送请求，此时服务器知道客户能发；
第二次握手：服务器发送确认，此时客户知道服务器能发能收；
第三次握手：客户发送确认，此时服务器知道客户能收。
建立连接(三次握手)：
第一次：客户向服务器发送连接请求段，建立连接请求控制段(SYN=1)，表示传输的报文段的第一个数据字节的序列号是x，此序列号代表整个报文段的序号(seq=x)；客户端进入 SYN_SEND (同步发送状态)；
第二次：服务器发回确认报文段，同意建立新连接的确认段(SYN=1)，确认序号字段有效(ACK=1)，服务器告诉客户端报文段序号是y(seq=y)，表示服务器已经收到客户端序号为x的报文段，准备接受客户端序列号为x+1的报文段(ack_seq=x+1)；服务器由LISTEN进入SYN_RCVD (同步收到状态);
第三次:客户对服务器的同一连接进行确认.确认序号字段有效(ACK=1),客户此次的报文段的序列号是x+1(seq=x+1),客户期望接受服务器序列号为y+1的报文段(ack_seq=y+1);当客户发送ack时，客户端进入ESTABLISHED 状态;当服务收到客户发送的ack后，也进入ESTABLISHED状态;第三次握手可携带数据;
5.6 TCP连接的四次挥手(重要)
释放连接(四次挥手)
第一次：客户向服务器发送释放连接报文段，发送端数据发送完毕，请求释放连接(FIN=1)，传输的第一个数据字节的序号是x(seq=x)；客户端状态由ESTABLISHED进入FIN_WAIT_1(终止等待1状态)；
第二次：服务器向客户发送确认段，确认字号段有效(ACK=1)，服务器传输的数据序号是y(seq=y)，服务器期望接收客户数据序号为x+1(ack_seq=x+1);服务器状态由ESTABLISHED进入CLOSE_WAIT(关闭等待)；客户端收到ACK段后，由FIN_WAIT_1进入FIN_WAIT_2；
第三次:服务器向客户发送释放连接报文段，请求释放连接(FIN=1)，确认字号段有效(ACK=1)，表示服务器期望接收客户数据序号为x+1(ack_seq=x+1);表示自己传输的第一个字节序号是y+1(seq=y+1)；服务器状态由CLOSE_WAIT 进入 LAST_ACK (最后确认状态)；
第四次：客户向服务器发送确认段，确认字号段有效(ACK=1)，表示客户传输的数据序号是x+1(seq=x+1)，表示客户期望接收服务器数据序号为y+1+1(ack_seq=y+1+1)；客户端状态由FIN_WAIT_2进入TIME_WAIT，等待2MSL时间，进入CLOSED状态；服务器在收到最后一次ACK后，由LAST_ACK进入CLOSED；
为什么需要等待2MSL?
最后一个报文没有确认；
确保发送方的ACK可以到达接收方；
2MSL时间内没有收到，则接收方会重发；
确保当前连接的所有报文都已经过期。
六、应用层
为操作系统或网络应用程序提供访问网络服务的接口。应用层重点：
数据传输基本单位为报文；
包含的主要协议：FTP(文件传送协议)、Telnet(远程登录协议)、DNS(域名解析协议)、SMTP(邮件传送协议)，POP3协议(邮局协议)，HTTP协议(Hyper Text Transfer Protocol)。
6.1 DNS详解
DNS(Domain Name System:域名系统)【C/S，UDP，端口53】：解决IP地址复杂难以记忆的问题,存储并完成自己所管辖范围内主机的 域名 到 IP 地址的映射。
域名解析的顺序：
【1】浏览器缓存，
【2】找本机的hosts文件，
【3】路由缓存，
【4】找DNS服务器(本地域名、顶级域名、根域名)->迭代解析、递归查询。
IP—>DNS服务—>便于记忆的域名
域名由点、字母和数字组成，分为顶级域(com，cn，net，gov，org)、二级域(baidu,taobao,qq,alibaba)、三级域(www)。
6.2 DHCP协议详解
DHCP(Dynamic Configuration Protocol:动态主机设置协议)：是一个局域网协议，是应用UDP协议的应用层协议。作用：为临时接入局域网的用户自动分配IP地址。
6.3 HTTP协议详解
文件传输协议(FTP)：控制连接(端口21)：传输控制信息(连接、传输请求)，以7位ASCII码的格式。整个会话期间一直打开。
HTTP(HyperText Transfer Protocol:超文本传输协议)【TCP，端口80】：是可靠的数据传输协议，浏览器向服务器发收报文前，先建立TCP连接，HTTP使用TCP连接方式(HTTP自身无连接)。
HTTP请求报文方式：
GET：请求指定的页面信息，并返回实体主体；
POST：向指定资源提交数据进行处理请求；
DELETE：请求服务器删除指定的页面；
HEAD：请求读取URL标识的信息的首部，只返回报文头；
OPETION：请求一些选项的信息；
PUT：在指明的URL下存储一个文档。
6.3.1 HTTP工作的结构
6.3.2 HTTPS协议详解
HTTPS(Secure)是安全的HTTP协议，端口号443。基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护。
免责声明：部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有。
七、TCP 和 UDP 是否可以同时监听绑定同一端口
问：TCP 和 UDP 可以同时监听相同的端口吗？
关于端口的知识点，还是挺多可以讲的，比如还可以牵扯到这几个问题：
多个 TCP 服务进程可以同时绑定同一个端口吗？
客户端的端口可以重复使用吗？
客户端 TCP 连接 TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗？
在此跟大家梳理一下这些问题。
TCP 和 UDP 可以同时绑定相同的端口吗？
「监听」这个动作是在 TCP 服务端网络编程中才具有的，而 UDP 服务端网络编程中是没有「监听」这个动作的。TCP 和 UDP 服务端网络相似的一个地方，就是会调用 bind 绑定端口，可以看一下TCP 和 UDP 网络编程的区别。
TCP 网络编程如下，服务端执行 listen() 系统调用就是监听端口的动作。
TCP 网络编程
UDP 网络编程如下，服务端是没有监听这个动作的，只有执行 bind() 系统调用来绑定端口的动作。
UDP 网络编程
TCP 和 UDP 可以同时绑定相同的端口吗？
答案：可以的。
在数据链路层中，通过 MAC 地址来寻找局域网中的主机。在网际层中，通过 IP 地址来寻找网络中互连的主机或路由器。在传输层中，需要通过端口进行寻址，来识别同一计算机中同时通信的不同应用程序。
所以传输层的「端口号」的作用，是为了区分同一个主机上不同应用程序的数据包。传输层有两个传输协议分别是 TCP 和 UDP，在内核中是两个完全独立的软件模块。
当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。
因此TCP/UDP 各自的端口号也相互独立，如 TCP 有一个 80 号端口，UDP 也可以有一个 80 号端口，二者并不冲突。
多个 TCP 服务进程可以绑定同一个端口吗？
还是以前面的 TCP 服务端程序作为例子，启动两个同时绑定同一个端口的 TCP 服务进程。
运行第一个 TCP 服务进程之后，netstat 命令可以查看，8888 端口已经被一个 TCP 服务进程绑定并监听了；运行第二个 TCP 服务进程的时候，就报错了“Address already in use”。
测试案例是两个 TCP 服务进程同时绑定地址和端口是：0.0.0.0 地址和8888端口，所以才出现的错误。如果两个 TCP 服务进程绑定的 IP 地址不同，而端口相同的话，也是可以绑定成功的。
所以在默认情况下，针对「多个 TCP 服务进程可以绑定同一个端口吗？」这个问题的答案是：如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同，那么执行 bind() 时候就会出错，错误是“Address already in use”。
注意，如果 TCP 服务进程 A 绑定的地址是 0.0.0.0 和端口 8888，而如果 TCP 服务进程 B 绑定的地址是 192.168.1.100 地址（或者其他地址）和端口 8888，那么执行 bind() 时候也会出错。因为 0.0.0.0 地址比较特殊，代表任意地址，意味着绑定了 0.0.0.0 地址，相当于把主机上的所有 IP 地址都绑定了。
重启 TCP 服务进程时，为什么会有“Address in use”的报错信息？
TCP 服务进程需要绑定一个 IP 地址和一个端口，然后就监听在这个地址和端口上，等待客户端连接的到来。在实践中可能会经常碰到一个问题，当 TCP 服务进程重启之后，总是碰到“Address in use”的报错信息，TCP 服务进程不能很快地重启，而是要过一会才能重启成功。
这是为什么呢？
当我们重启 TCP 服务进程的时候，意味着通过服务器端发起了关闭连接操作，于是就会经过四次挥手，而对于主动关闭方，会在 TIME_WAIT 这个状态里停留一段时间，这个时间大约为 2MSL。
当 TCP 服务进程重启时，服务端会出现 TIME_WAIT 状态的连接，TIME_WAIT 状态的连接使用的 IP+PORT 仍然被认为是一个有效的 IP+PORT 组合，相同机器上不能够在该 IP+PORT 组合上进行绑定，那么执行 bind() 函数的时候，就会返回了 Address already in use 的错误。
而等 TIME_WAIT 状态的连接结束后，重启 TCP 服务进程就能成功。
重启 TCP 服务进程时，如何避免“Address in use”的报错信息？
可以在调用 bind 前，对 socket 设置 SO_REUSEADDR 属性，可以解决这个问题。
int on = 1; setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
因为 SO_REUSEADDR 作用是：如果当前启动进程绑定的 IP+PORT 与处于TIME_WAIT 状态的连接占用的 IP+PORT 存在冲突，但是新启动的进程使用了 SO_REUSEADDR 选项，那么该进程就可以绑定成功。
举例，服务端有个监听 0.0.0.0 地址和 8888 端口的 TCP 服务进程。有个客户端（IP地址：192.168.1.100）已经和服务端（IP 地址：172.19.11.200）建立了 TCP 连接，那么在 TCP 服务进程重启时，服务端会与客户端经历四次挥手，服务端的 TCP 连接会短暂处于 TIME_WAIT 状态：
客户端地址:端口 服务端地址:端口 TCP 连接状态 192.168.1.100:37272 172.19.11.200:8888 TIME_WAIT
如果 TCP 服务进程没有对 socket 设置 SO_REUSEADDR 属性，那么在重启时，由于存在一个和绑定 IP+PORT 一样的 TIME_WAIT 状态的连接，那么在执行 bind() 函数的时候，就会返回了 Address already in use 的错误。
如果 TCP 服务进程对 socket 设置 SO_REUSEADDR 属性了，那么在重启时，即使存在一个和绑定 IP+PORT一样的 TIME_WAIT 状态的连接，依然可以正常绑定成功，因此可以正常重启成功。
因此在所有 TCP 服务器程序中，调用 bind 之前最好对 socket 设置 SO_REUSEADDR 属性，这不会产生危害，相反它会帮助我们在很快时间内重启服务端程序。
前面我提到过这个问题：如果 TCP 服务进程 A 绑定的地址是 0.0.0.0 和端口 8888，而如果 TCP 服务进程 B 绑定的地址是 192.168.1.100 地址（或者其他地址）和端口 8888，那么执行 bind() 时候也会出错。
该问题也可以由 SO_REUSEADDR 解决，因为它的另外一个作用是：绑定的 IP地址 + 端口时，只要 IP 地址不是正好(exactly)相同，那么允许绑定。
比如，0.0.0.0:8888 和192.168.1.100:8888，虽然逻辑意义上前者包含了后者，但是 0.0.0.0 泛指所有本地 IP，而 192.168.0.100 特指某一IP，两者并不是完全相同，所以在对 socket 设置 SO_REUSEADDR 属性后，那么执行 bind() 时候就会绑定成功。
客户端的端口可以重复使用吗？
客户端在执行 connect 函数的时候，会在内核里随机选择一个端口，然后向服务端发起 SYN 报文，然后与服务端进行三次握手。
所以客户端的端口选择发生在 connect 函数，内核在选择端口的时候，会从 net.ipv4.ip_local_port_range 这个内核参数指定的范围来选取一个端口作为客户端端口。
该参数的默认值是 32768 61000，意味着端口总可用的数量是 61000 - 32768 = 28232 个。
当客户端与服务端完成 TCP 连接建立后，我们可以通过 netstat 命令查看 TCP 连接。
$ netstat -napt
协议 源ip地址:端口 目的ip地址：端口 状态
tcp 192.168.110.182.64992 117.147.199.51.443 ESTABLISHED
那问题来了，上面客户端已经用了 64992 端口，那么还可以继续使用该端口发起连接吗？
这个问题，很多同学都会说不可以继续使用该端口了，如果按这个理解的话， 默认情况下客户端可以选择的端口是 28232 个，那么意味着客户端只能最多建立 28232 个 TCP 连接，如果真是这样的话，那么这个客户端并发连接也太少了吧，所以这是错误理解。
正确的理解是，TCP 连接是由四元组（源IP地址，源端口，目的IP地址，目的端口）唯一确认的，那么只要四元组中其中一个元素发生了变化，那么就表示不同的 TCP 连接的。所以如果客户端已使用端口 64992 与服务端 A 建立了连接，那么客户端要与服务端 B 建立连接，还是可以使用端口 64992 的，因为内核是通过四元祖信息来定位一个 TCP 连接的，并不会因为客户端的端口号相同，而导致连接冲突的问题。
多个客户端可以 bind 同一个端口吗？
bind 函数虽然常用于服务端网络编程中，但是它也适用于客户端的。
前面我们知道，客户端是在调用 connect 函数的时候，由内核随机选取一个端口作为连接的端口。而如果想自己指定连接的端口，就可以用 bind 函数来实现：客户端先通过 bind 函数绑定一个端口，然后调用 connect 函数就会跳过端口选择的过程了，转而使用 bind 时确定的端口。
针对这个问题：多个客户端可以 bind 同一个端口吗？
要看多个客户端绑定的 IP + PORT 是否都相同，如果都是相同的，那么在执行 bind() 时候就会出错，错误是“Address already in use”。
如果一个绑定在 192.168.1.100:6666，一个绑定在 192.168.1.200:6666，因为 IP 不相同，所以执行 bind() 的时候，能正常绑定。所以如果多个客户端同时绑定的 IP 地址和端口都是相同的，那么执行 bind() 时候就会出错，错误是“Address already in use”。
一般而言，客户端不建议使用 bind 函数，应该交由 connect 函数来选择端口会比较好，因为客户端的端口通常都没什么意义。
客户端 TCP 连接 TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗？
针对这个问题要看，客户端是否都是与同一个服务器（目标地址和目标端口一样）建立连接。如果客户端都是与同一个服务器（目标地址和目标端口一样）建立连接，那么如果客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。
但因为只要客户端连接的服务器不同，端口资源可以重复使用的。所以如果客户端都是与不同的服务器建立连接，即使客户端端口资源只有几万个， 客户端发起百万级连接也是没问题的（当然这个过程还会受限于其他资源，比如文件描述符、内存、CPU 等）。
如何解决客户端 TCP 连接 TIME_WAIT 过多，导致无法与同一个服务器建立连接的问题？
前面我们提到，如果客户端都是与同一个服务器（目标地址和目标端口一样）建立连接，那么如果客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。
针对这个问题，也是有解决办法的，那就是打开 net.ipv4.tcp_tw_reuse 这个内核参数。
因为开启了这个内核参数后，客户端调用 connect 函数时，如果选择到的端口，已经被相同四元组的连接占用的时候，就会判断该连接是否处于 TIME_WAIT 状态，如果该连接处于 TIME_WAIT 状态并且 TIME_WAIT 状态持续的时间超过了 1 秒，那么就会重用这个连接，然后就可以正常使用该端口了。
举个例子，假设客户端已经与服务器建立了一个 TCP 连接，并且这个状态处于 TIME_WAIT 状态：
客户端地址:端口 服务端地址:端口 TCP 连接状态
192.168.1.100:2222 172.19.11.21:8888 TIME_WAIT
然后客户端又与该服务器（172.19.11.21:8888）发起了连接，在调用 connect 函数时，内核刚好选择了 2222 端口，接着发现已经被相同四元组的连接占用了：
如果没有开启net.ipv4.tcp_tw_reuse 内核参数，那么内核就会选择下一个端口，然后继续判断，直到找到一个没有被相同四元组的连接使用的端口，如果端口资源耗尽还是没找到，那么 connect 函数就会返回错误。
如果开启了 net.ipv4.tcp_tw_reuse 内核参数，就会判断该四元组的连接状态是否处于 TIME_WAIT 状态，如果连接处于 TIME_WAIT 状态并且该状态持续的时间超过了 1 秒，那么就会重用该连接，于是就可以使用 2222 端口了，这时 connect 就会返回成功。
再次提醒一次，开启了 net.ipv4.tcp_tw_reuse 内核参数，是客户端（连接发起方） 在调用 connect() 函数时才起作用，所以在服务端开启这个参数是没有效果的。
客户端端口选择的流程总结
至此已经把客户端在执行 connect 函数时，内核选择端口的情况大致说了一遍，为了让大家更明白客户端端口的选择过程准备了一张流程图：
小结
TCP 和 UDP 可以同时绑定相同的端口。TCP 和 UDP 传输协议，在内核中是由两个完全独立的软件模块实现的。当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。因此TCP/UDP各自的端口号也相互独立，互不影响。
多个 TCP 服务进程可以同时绑定同一个端口吗？
如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同，那么执行 bind() 时候就会出错，错误是“Address already in use”。如果两个 TCP 服务进程绑定的端口都相同，而 IP 地址不同，那么执行 bind() 不会出错。
如何解决服务端重启时，报错“Address already in use”的问题？
当重启 TCP 服务进程的时候，意味着通过服务器端发起了关闭连接操作，于是就会经过四次挥手，而对于主动关闭方，会在 TIME_WAIT 这个状态里停留一段时间，这个时间大约为 2MSL。当 TCP 服务进程重启时，服务端会出现 TIME_WAIT 状态的连接，TIME_WAIT 状态的连接使用的 IP+PORT 仍然被认为是一个有效的 IP+PORT 组合，相同机器上不能够在该 IP+PORT 组合上进行绑定，那么执行 bind() 函数的时候，就会返回了 Address already in use 的错误。要解决这个问题可以对 socket 设置 SO_REUSEADDR 属性。这样即使存在一个和绑定 IP+PORT一样的 TIME_WAIT 状态的连接，依然可以正常绑定成功，因此可以正常重启成功。
客户端的端口可以重复使用吗？
在客户端执行 connect 函数的时候，只要客户端连接的服务器不是同一个内核，允许端口重复使用。TCP 连接是由四元组（源IP地址，源端口，目的IP地址，目的端口）唯一确认的，那么只要四元组中其中一个元素发生了变化，那么就表示不同的 TCP 连接的。所以，如果客户端已使用端口 64992 与服务端 A 建立了连接，那么客户端要与服务端 B 建立连接，还是可以使用端口 64992 的，因为内核是通过四元祖信息来定位一个 TCP 连接的，并不会因为客户端的端口号相同，而导致连接冲突的问题。
客户端 TCP 连接 TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗？
要看客户端是否都是与同一个服务器（目标地址和目标端口一样）建立连接。如果客户端都是与同一个服务器（目标地址和目标端口一样）建立连接，那么如果客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。即使在这种状态下，还是可以与其他服务器建立连接的，只要客户端连接的服务器不是同一个，那么端口是重复使用的。
如何解决客户端 TCP 连接 TIME_WAIT 过多，导致无法与同一个服务器建立连接的问题？
打开 net.ipv4.tcp_tw_reuse 这个内核参数。因为开启了这个内核参数后，客户端调用 connect 函数时，如果选择到的端口，已经被相同四元组的连接占用的时候，就会判断该连接是否处于 TIME_WAIT 状态。如果该连接处于 TIME_WAIT 状态并且 TIME_WAIT 状态持续的时间超过了 1 秒，那么就会重用这个连接，然后就可以正常使用该端口了。
参考：端口基础常识大全
该文章最后由 阿炯 于 2022-08-28 21:25:03 更新，目前是第 2 版。