| 七层参考模型 | 作用 | 举例 |
|---|---|---|
| 应用层 | 针对特定应用的协议 | |
| 表示层 | 设备固有数据格式和网络标准数据格式的转换 | |
| 会话层 | 通信管理，负责建立断开通信连接 | |
| 传输层 | 管理两个节点间的可靠数据传输，只在通信双方节点上处理，无需再路由器上处理 | TCP，UDP，SCTP，DCCP |
| 网络层 | 地址管理和路由选择 | 路由器（根据IP地址进行处理，可以连接不同的数据链路）IPv4，IPv6.. |
| 数据链路层 | 互联设备之间传送和识别数据帧 | 网桥（根据数据帧的内容转发给相邻的网络，两者速度可以不同）（根据MAC地址进行处理） |
| 物理层 | 负责比特流与电压高低灯光闪灭的互换 | 中继器（信号放大再生）（不能在传输速度不同的网络间转发） |
TCP/IP 体系结构不严格遵循 OSI 分层概念，应用层可能会直接使用 IP 层或者网络接口层。
| 四层参考模型 | 作用 | |
|---|---|---|
| 应用层 | 包含了OSI参考模型中的应用层，表示层，会话层，WWW、HTTP | |
| 传输层 | TCP、UDP | |
| 网际层 | IP、ICMP、ARP | |
| 网络接口层 |
在向下的过程中，需要添加下层协议所需要的首部或者尾部，而在向上的过程中不断拆开首部和尾部。
路由器只有下面三层协议，因为路由器位于网络核心中，不需要为进程或者应用程序提供服务，因此也就不需要传输层和应用层。
IP解决的是两端之间的连接，MAC地址解决的是到下一跳的连接
- 包：全能型术语
- 帧：数据链路层中包的单位
- 数据：是IP和UDP等网络层以上分层中包的单位
- 段：表示TCP数据流中的信息
- 消息：应用协议中数据的单位
TCP/IP协议对数据链路层与物理层未作定义，这是以这两层的功能是透明的为前提。
数据链路层协议定义了通过通信媒介互联的设备之间传输的规范。
MAC地址用于识别数据链路中互连的节点。
MAC地址长48bit，MAC地址一般烧入网卡的ROM中，任一网卡的MAC地址都是唯一不可重复的。
MAC地址：70-BC-10-74-9C-C9
01110000-10111100-00010000-01110100-10011100-11001001
- 第1位：单播地址（0）/多播地址（1）
- 第2位：全局地址（0）/本地地址（1）
- 3-24位：IEEE管理，保证各厂商不重复
- 25-48位：各厂商管理，保证产品不重复
半双工与全双工通信： 半双工：只发送或只接收 全双工：同时发送接收
在使用同轴电缆的以太网等介质共享网络中，交换集线器/以太网交换机，即网桥，根据数据链路层中的每个帧的目标MAC地址，决定从哪个网络接口发送数据。这时所参考的用于记录发送接口的表叫转发表。
转发表的自学过程：数据链路层的每个通过点在接到包时，会从中将源MAC地址与曾经接收该地址发送的数据包的接口作为对应关系记录到转发表中。
当设备增加时，转发表也随之变大，当连接多个终端时有必要将网络分为多个数据链路，采用类似网络层IP地址一样的分层管理模式。
环路
- 缺点：通过网桥连接网络时，最坏的情况数据帧在环路中被持续转发，数据帧越来越多导致网络瘫痪。
- 优点：分散网络流量，提高容灾能力
环路检测技术：
- 生成树方式：每个网桥必须在1~10秒内互相交换BPDU（Bridge Protocol Data Unit）包，判断哪些端口使用那些不使用，以便消除环路。
- 源路由法：判断发送数据的源地址是通过哪个网桥传输的，并将帧写入RIF（Routing Information Field），网桥根据这个RIF发送帧给目标地址。
VLAN通过对某一台交换机按端口区分多个网段，从而区分了广播数据传播范围，减少了网路负载并提高了网络安全性。
数据链路层包的单位叫帧。
以太网前端有一个前导码部分，8个字节，64位。
前导码末尾8位是11，称为SFD域，在这个域后就是以太网本体。
以太网帧本体前端是以太网首部，占14个字节，分别是6个字节的目标MAC地址，6个字节的源MAC地址以及来个字节的上层协议类型。
紧随帧头后面的是数据。一个数据帧所能容纳最大数据范围是46~1500个字节。帧尾是4个字节的FCS（帧检验序列），错误帧会被直接丢弃。
数据链路层进一步细分可分为介质访问控制层（MAC）和逻辑链路控制层（LLC），介质访问控制层根据以太网或FDDI等不同数据链路所特有的首部信息进行控制，逻辑链路从根据不同数据链路所共有的帧头信息控制。
互联网层由IP（Internet Protocol）与ICMP（Internet Control Message Protocol）两个协议组成。
网络层主要实现“终端节点之间的通信”，网络层可以跨越多个数据链路实现数据包的传输。
数据链路层负责两个直连设备间的通信，而网络层的IP则在没有直连的两个网络间通信传输。
TCP/IP通信中所有主机和路由器都必须设定自己的IP地址。而在网桥、交换集线器这种物理层或数据链路层的设备中则不需要IP地址。
路由控制是指将分组数据发送到最终目标地址的功能。
路由控制表：所有主机都维护了一张路由控制表（Routing Table），该表记录IP数据在下一步应该发给哪个路由。
IP面向无连接：简化，提速。 IP提供尽力服务，并不做最终收到与否的验证。
IPv4地址由32位正整数构成：网络地址+主机标识。IP地址分为四个级别。
- A类：首位为0的地址，1~8为是网络标识，即0.0.0.0-127.0.0.0；
- B类：前两位是10的地址，1~16位是网络标识，即128.0.0.1-191.255.0.0；
- C类：前两位是110的地址，1~24位是网络标识，即192.168.0.0-239.255.255.0；
- B类：前两位是1110的地址，1~32位是网络标识，即224.0.0.1-239.255.255.255，没有主机标识，常被用作多播。
IP地址不可为0.0.0.0（IP地址不可获知）或1.1.1.1（多播）
IPv6具有128位，8个字节
广播地址用于在同一个链路中发送广播数据。IP地址中主机部分全设置为1，就形成的广播地址。 广播无法穿透路由。
- 本地广播：本网络内广播的地址
- 直接广播：不同网络间的广播
多播：可以穿透路由
为了避免IP地址浪费，增加子网掩码。
子网掩码：32位，它对应的网络部分标识全为1，对应IP地址主机标识部分全为0。由此一个IP地址不再受限于自己的类别
CIDR：无类型域间选路，解决全局IP地址不够用的问题
私有IP地址：
- 10/8
- 172.16/12
- 192.168/16
私有IP通过NAT与全局地址的主机通信
Ip地址的网络部分用于路由控制。每一路由控制表中记录的网络地址与下一步应该发送至路由器的地址。
- 默认路由：可以匹配任一地址，0.0.0.0/0
- 主机路由：整个IP地址的所有位都将参与路由，进行主机路由意味着要基于主机上网卡配置的IP地址本身，而不是基于该地址的网络地址部分进行路由，主机路由多被用于不希望通过网络地址路由情况。IP地址/32
- 环回地址：同一台计算机上的程序之间进行网络通讯时默认的地址，127.0.0.1
查看路由表：route -n
路由表包括
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.17.128.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 0.0.0.0 172.17.143.253 0.0.0.0 UG 0 0 0 eth0
当TCP/IP需要向某个IP地址发起通信时，它会对路由表进行评估，以确定如何发送数据包。评估过程如下：
- TCP/IP使用需要通信的目的IP地址和路由表中每一个路由项的网络掩码进行相与计算，如果相与后的结果匹配对应路由项的网络地址，则记录下此路由项。
- 当计算完路由表中所有的路由项后，
- TCP/IP选择记录下的路由项中的最长匹配路由（网络掩码中具有最多“1”位的路由项）来和此目的IP地址进行通信。
- 如果存在多个最长匹配路由，那么选择具有最低跃点数的路由项。
- 如果存在多个具有最低跃点数的最长匹配路由，那么：均根据最长匹配路由所对应的网络接口在网络连接的高级设置中的绑定优先级来决定(一般有线(eth0) > 无线 (wlan0) > 移动信号(4G))。
- 如果优先级一致，则选择最开始找到的最长匹配路由。
MTU：MTU是指最大传输单元
IP分片：在网络传输的过程中，由于不同数据链路的MTU不同，当一个IP数据报无法在一个帧当中完成发送时，路由器就会将IP数据报分片发送。但是分片机制会使路由器的负荷加重。
路径MTU：从发送端主机到接收端主机之间不需要分片时最大MTU的大小。
路径MTU发现原理：发送端主机发送IP数据报时，将首部的禁止标志为设置为1，根据这个标志位，途中的路由器即使遇到需要分片处理才能处理的大包，也不会进行分片，而是将其丢弃，随后通过一个ICMP的不可达消息，数据链路上的MTU值发送给主机。下一次，从发送给同一个目标主机的IP数据报获得ICMP所通知的MTU值以后，将它设置为当前MTU，直到数据报被发送到目标主机为止没有收到任何ICMP。
DNS系统是一个可以有效管理主机名和IP地址之间对应关系的系统。
DNS域名系统工作原理：
- 查询浏览器、操作系统缓存
- 首先解析器向本地域名服务器进行查询，本地域名服务器会首先在自己的数据库中查找，如果该域名的IP地址存在，那么就直接返回，如果没有，就会再向上一层根域名服务器进行查询处理。
- 根域名服务器返回所查询域的主域名服务器（主域名、顶级域名，如com、cn）。
- 本地域名服务器请求主域名服务器，获取该域名的名称服务器（域名注册商服务器）；
- 本地域名服务器向名称服务器请求域名IP映射；
- 缓存解析结果，减少每次查询时的性能消耗。
不同的解析记录：
- A类型 ，主机名的IP地址，IPv4
- CNAME，主机别名对应的规范名称，
- PTR，IP地址的反向解析，从IP地址检索主机名。
ARP（Address Resolution Protocol，地址解析协议 ）机制：以目标IP地址为线索，用来定位下一个应该接收数据分包的网络设备对应的MAC地址。如果目标主机不在同一链路时可以通过IP查找下一跳路由器的MAC地址。
ARP的工作机制：
每台主机都有一个ARP列表，存放IP与MAC地址的关系
- 源主机首先查看ARP列表中待查看IP地址对应的目标主机的MAC地址，如果找到直接发送数据；
- 如果找不到，就向该网段广播ARP请求包，其中包含了源IP地址，源MAC地址和目的IP地址，而目的地收到请求包后，会将源IP地址和源MAC地址存入自己的ARP列表中，并自己的MAC地址填入ARP响应包返回给源主机。
IP可以动态地进行地址解析，所以在TCP/IP网络构造和通信中只要有IP地址即可。 广播ARP请求，单播ARP响应。
RARP（Reverse Address Resolution Protocol）：从MAC地址定位IP地址的协议
ICMp提供验证网络设置是否正确的功能。IP通信中具体某个IP包未能到达目的地址的的原因将由ICMP负责通知。
ICMP消息包括：不可达消息、重定向消息、超时消息、重回消息
DHCP（Dynamic Host Configuration Protocol）：通过DHCP服务器自动分配IP。
架设一台或多台DHCP服务器，当DHCP服务器发现包时，会向客户端指定IP地址和子网掩码。
NAT（Network Address Translator）：将本地网络中的私有IP地址转换位全局IP地址。
NAT内部自动生成一张地址转换表
IP隧道可以将IPv6包统合为一个数据再加上IPv4的首部进行转发。
在网络层首部后继续追加网络层首部的通信方法叫做“IP隧道”。
TCP（传输控制协议）：面向连接的可靠的流协议 UDP（用户数据协议）：不可靠的数据报协议
运输层协议是通过在端系统而不是网络路由器实现的。在发送方，运输层将接收到的来自应用进程的报文转换成运输层报文段（Segment），并为其加上运输层首部，传递给网络层。
网络层只把分组发送到目的主机，但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信，传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。
- 套接字有唯一标识符
- 每个报文段有特殊字符来指示该报文段所要交付的套接字：源端口号和目的端口号
TCP套接字是由一个四元组（源IP，源端口，目的IP，目的端口）标识的，主机使用全部四个值将报文定向（多路分解）到相应的套接字。
UDP报文段包括：源端口号，目的端口号，长度，校验和，应用数据。12字节的伪首部是为了计算校验和临时添加的。
选择重传（SR）协议：发送方仅重传它怀疑接收方出错的分组，避免不必要的重传。
发送方：
- 从上层接受应用数据：检查下一个可用于该分组的序号，如果序号在窗口内则打包发送，否则缓存或返回上层；
- 超时：每个分组具有独立的定时器；
- 收到ACK：如果收到ACK，且分组序号在窗口内，则SR发送方讲被确认的分组标记为已接收。如果该分组的序号等于send_base，则窗口向前移动到具有最小序号的未确认分组处。
接收方：
- 正确接收：接收方接受到在当前工作窗口内的分组时，将向发送放发送ACK，如果该分组是以前没收到分组则缓存，如果该分组的学号等于接收窗口的基序号，那么这个窗户将向前移动到具有最小序号的未接受分组处。
- 序号在前一个窗口中的分组被接收：重复接收时也必须返回一个ACK，以免发送方的分组窗口不可向前继续滑动。
窗口的长度必须小于或等于序号空间大小的一半。
| 机制 | 用途与说明 |
|---|---|
| 检验和 | 用于检测在一个传输分组中的比特错误 |
| 定时器 | 用于检测超时重传一个分组，可能接收方会收到冗余拷贝 |
| 序号 | 用于为从发送方流向接收方数据分组按顺序编号，为了避免序号重复使用，TCP网络中一个序号的寿命被假定在三分钟。 |
| ACK/NAK | 用于接收方告知发送方是否正确接收到 |
| 窗口、流水线 | 允许一次发送多个分组但未被确认。提高发送方的利用率，窗口长度可根据接收方接受和缓存报文的能力和网络中的拥塞情况来进行设置。 |
- 序号 ：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
- 确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
- 数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
- 确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
- 同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
- 终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
- 窗口 ：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
连续ARQ协议：所谓连续就是在发送完一个数据帧后，不是停下来等待确认帧，而是可以连续再发若干帧，边发可以边等待确认帧，如果收到了确认帧，又可以继续发送数据帧， 由于减少了等待的时间，利用率就提高了。但是连续ARQ在收到一个否认帧或超时后，所有该帧后面的帧都要重发而不管该帧后面的帧是否正确传送于是便有了选择重传ARQ协议。
滑动窗口协议：允许发送方发送多个分组而不需等待确认。
- 客户端发送确认序号SYN=1，ACK=0，初始序号seq=X的包，连接的服务器的端口。
- 服务端返回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号设置为x+1。并发送一个自己的序列号 y。
- 客户端发送确认包(ACK) SYN标志位为0，ACK标志位为1，并且把服务器发来的 y+1 作为确认号发送给对方，且序列号设置为第二次的确认号x+1。
第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。
TCP连接是全双工的，因此每个方向都必须单独进行关闭。
- A 发送连接释放报文，FIN=1。
- B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
- 当 B 不再需要连接时，发送连接释放报文，FIN=1。
- A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
- B 收到 A 的确认后释放连接。
客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。
TIME_WAIT
客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：
- 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
- 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。
TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信； 而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。
对于可靠性，TCP通过以下方式进行保证：
- 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
- 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
- 丢弃重复数据：对于重复数据，能够丢弃重复数据；
- 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认ack，这个ack的值是期望收到的下一个字节序号；
- 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段，超时时间是RTTs+4*RTTd，平均往返时间加4倍偏差的加权平均值；
- 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。
发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。
流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
拥塞控制的方法主要有以下四种：
发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
-
慢启动：发送方开始只能发送 1 个报文段，当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ... ， 设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免
-
拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
-
快重传 ：发送方如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段，而不用等待超时。
-
快恢复：当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。
- 用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。
- 传输控制协议 TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。
服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认
DDos 攻击
- 客户端向服务端发送请求链接数据包
- 服务端向客户端发送确认数据包
- 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认
DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )
- 限制同时打开SYN半链接的数目
- 缩短SYN半链接的Time out 时间
- 关闭不必要的服务
这种情况比较常见，一些爬虫服务器或者WEB服务器（如果网管在安装的时候没有做内核参数优化的话）上经常会遇到这个问题，这个问题是怎么产生的呢？
从 上面的示意图可以看得出来，TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定 的，主要出于以下两个方面的考虑：
1.防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失） 2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。
解决思路很简单，就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
- 对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255，默认值是5，对应于180秒左右时间
- 当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒
- 如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间：net.ipv4.tcp_fin_timeout=30
- SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
- 开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
- 开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接
- 开启TCP连接中TIME-WAIT sockets的快速回收
- 减少超时前的探测次数
如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。
DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输：
- 如果返回的响应超过的 512 字节（UDP 最大只支持 512 字节的数据）。
- 区域传送（区域传送是主域名服务器向辅助域名服务器传送变化的那部分数据）。
FTP 使用 TCP 进行连接，它需要两个连接来传送一个文件：
- 控制连接：服务器打开端口号 21 等待客户端的连接，客户端主动建立连接后，使用这个连接将客户端的命令传送给服务器，并传回服务器的应答。
- 数据连接：用来传送一个文件数据。
根据数据连接是否是服务器端主动建立，FTP 有主动和被动两种模式：
-
主动模式：服务器端主动建立数据连接，其中服务器端的端口号为 20，客户端的端口号随机，但是必须大于 1024，因为 0~1023 是熟知端口号。
-
被动模式：客户端主动建立数据连接，其中客户端的端口号由客户端自己指定，服务器端的端口号随机。
主动模式要求客户端开放端口号给服务器端，需要去配置客户端的防火墙。被动模式只需要服务器端开放端口号即可，无需客户端配置防火墙。但是被动模式会导致服务器端的安全性减弱，因为开放了过多的端口号。
GET：获取资源 HEAD：获取报文首部（用于获取报文首部，用于确认URL有效性） POST：传输数据 PUT：上传文件（不带验证机制，一般不使用） PATCH：对资源进行部分修改 DELETE：删除文件，不带验证机制 OPTION：查询支持的方法 CONNECT：要求在与代理服务器通信时建立隧道 TRACE：追踪路径
GET 用于获取资源，而 POST 用于传输实体主体。
GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如 Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB 从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大。 Http Get方法提交的数据大小长度并没有限制，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。 POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。 理论上讲，POST是没有大小限制的。HTTP协议规范也没有进行大小限制，起限制作用的是服务器的处理程序的处理能力。
非持久连接：每个TCP连接在服务器只传输一个请求报文和一个响应报文，返回对象后立即关闭。
持久连接：服务器在发送响应后保持TCP链接打开，一个完整的Web页面可以用单个连接传送。一段时间若未被使用自动关闭。（HTTP/1.1之后默认）
请求报文：
GET /dir/index.html HTTP/1.1 //请求行：方法字段+URL+HTTP协议
Host: www.some.com //首部行
Connection: Keep-Alive
User-agent: Mozilla/4.0
Accept-language: en-us
//实体主体响应报文：
HTTP/1.1 200 OK //初始状态行：协议版本+状态码+相应状态信息
Date: Sun, 08 Feb xxxx 01:11:12 GMT //首部行
Server: Apache/1.3.29 (Win32)
Last-Modified: Sat, 07 Feb xxxx
ETag: "0-23-4024c3a4"
//实体主体- 2XX ：成功状态码
- 200 OK ：请求成功，信息包含在返回的响应报文中
- 3XX：重定向
- 301 Moved Permanently：请求的对象永久转移了， 搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址
- 302 Moved Temporarily : 暂时性转移， 搜索引擎会抓取新的内容而保存旧的网址。
- 4XX：客户端错误
- 400 Bad Request：通用差错码，该请求不能被服务器理解。
- 403 Forbidden：禁止访问
- 404 Not Found：被请求的文档不在服务器上
- 5XX：服务端错误
- 500 Internal Server Error
- 503 Server Unavailable
- 创建过程
- 当用户第一次访问某网站时，请求报文到达服务器后，Web站点会产生一个唯一识别码，并以此作为索引在其后端数据库中产生一个表项。
- 服务器发送的响应报文包含Set-Cookie首部字段，客户端得到后将Cookie内容保存在浏览器
- 客户端之后对同一个服务器发送请求时，会从浏览器中取出Cookie信息并通过Cookie请求首部字段发送给服务器
- 这样站点可以跟着用户访问了哪些页面，按照什么顺序，在什么时间
- 分类&作用域
- 会话期Cookie/持久性Cookie
- 作用域标识主机下那些路径可以接受Cookie
除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。
什么是Session
Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
session的两种实现方式（也就是传递方式）：第一种通过cookies实现。第二种通过URL重写来实现
第一种方式的理解：就是把session的id 放在cookie里面（为什么是使用cookies存放呢，因为cookie有临时的，也有定时的，临时的就是当前浏览器什么时候关掉即消失，也就是说session本来就是当浏览器关闭即消失的，所以可以用临时的cookie存放。保存再cookie里的sessionID一定不会重复，因为是独一无二的。），当允许浏览器使用cookie的时候，session就会依赖于cookies，当浏览器不支持cookie后，就可以通过第二种方式获取session内存中的数据资源。
第二种方式的理解：在客户端不支持cookie的情况下使用。为了以防万一，也可以同时使用。
- 优点：
- 降低服务器压力
- 降低客户端延迟
- 方法：
- 搭建代理服务器，让代理服务器进行缓存
- 让客户端浏览器进行缓存
如果网络出现中断，服务器只发送了一部分数据，范围请求可以使得客户端只请求服务器未发送的那部分数据，从而避免服务器重新发送所有数据。
在请求报文中添加Range首部
HTTP有安全性问题：
- 明文通信
- 不言中通信方身份，有可能在于伪装
- 无法证明报文完整性
HTTPS是让HTTP先与SSL通信，再由SSL和TCP通信，即HTTPS使用了隧道通信。
通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。
HTTPS在传输的过程中会涉及到三个密钥：
服务器端的公钥和私钥，用来进行非对称加密
客户端生成的随机密钥，用来进行对称加密
一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。 1.客户端向服务器发起HTTPS请求，连接到服务器的443端口
2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3.服务器将自己的公钥发送给客户端。
4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7.然后服务器将加密后的密文发送给客户端。
8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
- 对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。无法安全地将密钥传输给通信方。
- 非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。
- 混合的加密机制 使用非对称密钥加密方式，传输对称密钥加密方式所需要的 Secret Key，从而保证安全性； 获取到 Secret Key 后，再使用对称密钥加密方式进行通信，从而保证效率。
通过使用 证书 来对通信方进行认证。
数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。
服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。
进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。
SSL 提供报文摘要功能来进行完整性保护。
HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。
HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。
- 因为需要进行加密解密等过程，因此速度会更慢；
- 需要支付证书授权的高额费用。
HTTP/1.x 实现简单是以牺牲性能为代价的：
- 客户端需要使用多个连接才能实现并发和缩短延迟；
- 不会压缩请求和响应首部，从而导致不必要的网络流量；
- 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。
HTTP/2.0 将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。
在通信过程中，只会有一个 TCP 连接存在，它承载了任意数量的双向数据流（Stream）。
- 一个数据流（Stream）都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
- 消息（Message）是与逻辑请求或响应对应的完整的一系列帧。
- 帧（Frame）是最小的通信单位，来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。
HTTP/2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，客户端就不需要再次发起请求了。例如客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。
HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。
不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。
- 域名解析
- 为了将消息从你的PC上传到服务器 上需要用到1P协议、ARP协议和0SPF协议
- 发起TCP的3次握手
- 建立TCP连接后发起http请求
- 服务器响应htp请求
- 浏览器解析htm代码,并请求html代码中的资源(如js、css、图片等）
- 断开TCP连接
- 浏览器对页面进行渲染呈现给用户
手机扫码二维码实现登录某个网站的操作过程为，手机登录某个APP，利用“扫一扫”功能扫描网页上的二维码，扫描成功后，提示“登录网页版XX”，同时网页上显示“成功扫描 请在手机点击确认以登录”，手机端点击“登录网页版XX”，网页跳转到用户登录后的首页。
- PC浏览器首先获得一个临时 id，这个id用二维码包装着，并且设置了有效时间，这个id不是UID（user ID），只是一个唯一的由字母和数字组合成的标识符。
- 等待客户端扫描带有此 id 的二维码，二维码的转码规则是统一的，所以意味着，只要是个二维码扫描软件，谁都能拿到这个链接。
- PC端浏览器通过长连接或不断轮询某个登录授权接口，查看与此id关联的二维码是否被手机客户端扫描。手机客户端扫描时，会给后端服务器（无论手机还是网页都对应着后端同一个或有相互关系的服务器）传送这个id，即发送一条信息给服务器，告诉服务器，现在是谁使用了这个二维码链接。
- 服务器在收到这个id后，在给PC浏览器的长连接或轮询请求中响应一些不同的信息说明该二维码链接被扫描了，并要求在手机端去确认。当手机客户端点击确认后，pc浏览器端会获得服务器授信的令牌（或设置的sessionID），这样PC浏览器就可以携带这个令牌进行随后的信息交互。