将IP地址中的主机地址全部设为0，就为网络号，代表这个局域网
将iP地址全部设为1，就成为了广播地址，用于给同一个链路中相互连接的所有主机发送数据包。
127.*的iP地址用于本机回环(Loop  Back)测试，通常是127.0.0.1
本机环回主要用于本机到本机的网络通信（系统内部为了性能，不会走网路传输方式），对于网络编程而言 常见的开发方式都是本机到本机的网络通信。

子网掩码

意义

：单位一般会申请b类的网络，但实际架设，连接的主机数量远远小于B类连接主机数，造成IP地址浪费，当一个单位为了将一个IP地址分发给下属单位，重新申请会造成浪费，因此出现了子网掩码来解决浪费的问题。

格式

子网掩码的合适和IP地址一样们也是32位的二进制数，左边是网络位，‘1’的数目等于网络位的长度，右边是主机位，用二进制的0表示，0的数目等于主机位的长度。子网掩码也可以使用二进制所有高位1相加起来的数值表示，

作用

划分A\B\C三类IP地址子网 ? 网络通信的时候，子网掩码结合Ip地址，可以计算或得网络号（划分子网后的网络号）主机号（划分子网后的主机号）。一般用于判断目的Ip与本Ip是否为同一个网段。

计算方式

将IP地址和子网掩码进行“按位与” 操作（二进制相同位、与操作，两个都是1结果为1，否则为0），得到的结果就是网络号，
?
将子网掩码二进制按位取反，再与IP地址位与计算 得到的就是主机号。

MAC地址

概念

用于标识网络设备的硬件物理地址， ? 主机有一个或者多个网卡，路由器有两个以上的网卡，每一个网卡都有唯一一个MAC地址。 ? 网络数据传输本质上是网络硬件设备，将数据发送到网卡上，或者从网卡接受数据。 ? 硬件层面，只能基于MAC地址识别网络设备的网路物理地址。 ? MAC地址用来识别数据链路层中相连的节点 ? 长度为48位，以及6个字节，一般用16进制加上冒号的形式表示 ? 网卡在出厂的时候就确定了，不能修改，虚拟机中的MAC地址不是真实的MAC地址。

特殊的MAC地址

广播数据报，发送一个广播数据报，表示对同网段所有主机发送数据报，广播数据报的MAC地址为：FF:FF:FF:FF:FF:FF

网络和数据传输

方式：一跳一跳的网络数据传输 ? 网路数据传输不是想象中的，从源主机到达目的主机而是类似图中的描述 ? TODO：图片的截取和理解

IP地址和MAC地址总结

IP地址是路途总体的起点和终点是给人使用的网络逻辑地址。 ? MAC地址描述的是路途上的每一个区间的起点和终点，每一跳的起点和终点，给网络哦硬件设备使用的网络物理地址。

网络设备以及相关的技术

集线器：转发所有的端口

集线器是工作在物理层的网络设备，发送到集线器的任何数据，都只是简单的将数据复制并且转发到其他所有的端口（端口指的是集线器后边的物理端口）

交换机： MAC地址转换表+转发对应端口

交换机工作在数据链路层，交换机内部会记录并且维护以后在那个MAC地址表 ? MAC地址转换表主要记录MAC地址与端口之间的映射 ? 主机连接到交换机，以及主机发送数据的时候，交换机可以学习并且记录该主机的MAC地址与端口信息 ? 交换机接收到数据报以后，在MAC地址转换表中，通过目的MAC查找到对应的端口，只需要将数据报转发到对应的端口上 ? 以上使用的是MAC地址转换表，通过目的MAC能找到对应端口的情况；如果找不到，交换机设置数据报目的MAC为广播地址，发送到所有的端口，目的主机返回响应之后，交换机再记录该主机MAC与端口的映射信息。

主机

网络分层从上到下封装

主机和路由器：ARP缓存表+ ARP寻址

ARP是介于数据链路层和网络层之间的协议，ARP协议建立了IP地址与MAC地址的映射关系 ? 在数据链路层，寻找下一跳设备MAC地址的过程称为ARP寻址 ?

     主机和路由器中都保存了一张ARP缓存表；通过IP地址可以找到对应的 MAC地址，
     根据下一跳设备的IP地址没在ARP缓存表中能找到对应的MAC地址，则可以设置目的MAC并发送数据报
     如果找不到，发送ARP广播数据包：目的MAC为广播地址，询问下一跳设备的MAC地址。（类似于qq群喊话）

路由器：路由+NAPT

网关

路由器作为网关，可以划分局域网和公网，某些路由器还以将局域网划分为多个子网（不同网段） ? tips：家用路由器不能划分局域网和子网，企业级路由器才可以划分子网和局域网 ? 路由器作为网关 ? 1.划分局域网多个子网的时候，可以直接通过ARP寻址找到局域网任意主机（这里的局域网指的就是，由路由器下的多个子网组成的局域网） ? 2.划分公网和局域网时，局域网内主机发送数据库到公网主机的时候，需要基于NAPT协议，将局域网主机的IP地址和端口号，转换为路由器公网IP和端口号。

路由

路由就是在复杂的网路结构中找出一条通往终点的路线。

功能：网络通信（网路数据传输），类似于规划路线，从那个方向走可以更快的到达目的地

冲突域

主机之间通过网络设备（集线器、交换机）的物理端口、网线相连的时候，两个主机在同一时刻同时发送数据报，如果存在冲突，则该网络范围为一个冲突域 ? 冲突域是基于第一物理层，又被称为冲突域 ? 集线器是将数据简单的复制之后转发给其他的所有端口，如果有两个数据报要同时进行转发，就会出现冲突域，整个的集线器的所有端口为一个冲突域 ? 而交换机再接收到数据报的时候，是将数据报转发到对应的一个端口：两个数据报同时转发到一个端口就会出现冲突，分割之后每一个端口为一个冲突域。

广播域

概念：

广播是指某个网络中的主机同时向网络中的其他所有主机发送数据，这个数据所能传播的范围即为广播域。 广播域基于第二数据链路层集线器收到广播数据之后，仍然是简单的复制，转发到其他的端口，所以集线器的所有端口为一个广播域交换机接收到广播数据的时候会转发到其他的所有端口么路由器可以隔离广播域

网络数据传输流程

局域网传输流程：集线器

使用集线器网络互联的情况下，发送端主机发送数据包的时候，需要从上到下封装数据报。但是封装的时候，目的MAC可能并不知道，需要先进行ARP寻址， ?

1.发送端在本机ARP缓存表中，根据目的IP查找对应的MAC地址
         2如果找到，则可以在数据链路层以太网帧中设置 目的MAC并发送数据包
         3如果没有找到需要先发送ARP广播请求，目的主机告诉自己目的MAC是多少行
         4发送端更新本机ARP缓存表，保存的IP与目的MAC映射
         5.有了目的MAC 就可以按照地2个步骤进行发送

局域网传输流程：交换机

交换机MAC地址转换表

局域网传输流程：交换机+路由器

子网掩码、网关

广域网数据传输流程

DNS、NAPT\路由

面试题：在浏览器中输入URL之后后面所发生的事情

简易版：
在浏览器中输入URL之后首先会进行DNS解析的操作，
然后客户端与服务器进行TCP三次握手，
客户端发送http请求
服务器发送http响应
浏览器进行资源和页面的渲染
最后TCP四次挥手断开连接

应用层的重点协议

DNS

概念：

Domain name System 域名系统  是一整套从域名映射到Ip的系统域名的发明是因为Ip地址不方便记忆，并且人们通过域名系统来映射域名和IP地址。
域名就是一串字符串 域名系统为一个树形结构，=包含了很多根节点
根节点即为根域名服务器，最早的IPv4 根域名服务器全球只有13台，Ipv6 扩充数量
子节点主要由各级DNS服务器，或者DNS缓存构成dns域名服务器就是提供域名转换为ip地址的服务器、浏览器、主机系统、路由器中都保存着DNS缓存

windows DNS缓存: C:windows\System32\dirvers\etc\hosts** ? LInux DNS缓存： /etc/hosts** ? 在网络发送数据的时候使用目的主机的域名就需要先通过域名解析查到对应的IP地址

域名解析的过程：

发送端主机作为域名系统树形结构的一个子节点通过域名信息，从下到上查找对应Ip地址的过程，如果到根节点（根域名服务器）还没有找到就说明找不到该主机域名解析使用DNS协议来传输数据。DNS协议是应用层协议、基于传输层的UDP、TCP来实现。

NAT

背景：

NAT技术是解决IPV4协议中的 Ip地址数量不足的问题

手段：

将私有Ip和全局ip相互转换的技术方法这也是路由器的重要功能

很多学校 、家庭、公司内部采用每个终端设置私有iP，而在路由器上设置全局ip
         全局ip要求唯一，但私有ip不需要，在不同的局域网中可以出现相同的私有IP

缺陷

无法从NAT外部向内部服务器建立连接 ? 准换表的生成和销毁都会造成开销 ? 通信的过程NAT一旦出现异常即使设备存在所有的tCP都会断开

NAT IP转换过程

NAT路由器将原地址从 10.0.0.10 替换为全局Ip 202.244.174.37 ? NAT路由器在收到外部数据的时候，又会自动的替换全局ip为10.0.0.10 ? 在NAT路由内部，有一张自动生成的，用于地址转换的表 ? 当10.0.0.10第一次向163.221.120.9 发送数据的时候就会生成表中的映射关系 ?

NAPT

背景：局域网内，多个主机同时访问同一个外网服务器，那么就必须使用NAPT来解决问题：采用IP+port 来建立这个联系

而这种关联联系也是由NAT路由器自动维护的，例如在TCP的情况下建立连接时就会生成这个表，但是断开的时候会删除这个表

HTTP

http的常用状态码

1**：信息性状态码

2**：成功状态码

3**：重定向状态码

4**：客户端错误状态码

5**：服务端状态错误码

101：切换请求协议
200：请求成功
301：请求资源永久移动，返回新的URL
302：请求资源临时移动，继续使用原来的URL
400：客户端请求的语法错误，服务端无法理解
401：当前的请求需要认证
403：服务端理解请求，但是拒绝执行
404 Not Found ： 请求的资源不存在，比如输入了错误的URL。
500：服务器内部出错

301与302的区别

301：永久性移动，请求的资源已被永久移动到新的位置，服务器返回该响应的时候，会返回新的资源地址。 302：临时性移动，服务器从另外的地址响应资源，但是客户端还应该使用这个地址

HTTP的请求方法

GET  对服务器获取资源的简单请求
POST  向服务器提交数据请求
PUT ? 修改指定的资源
DELETE  删除URL标记的指定资源
CONNECT  用于代理服务
TRANCE ? 主要用于回环测试
OPTIONS  返回所有的可用方法
HEAD ? 获取URL标记资源的首部

说明GET和POST 的区别

1.http报文层面来看的话 GET请求将信息放在URL ，POST将请求信息放在请求体重中。
?
2.从数据库的层面来看的话 ，get符合幂等性和安全性 ，post不符合。
?
3.从其他的层面来看 get请求能够被缓存，可以保存在浏览器的浏览记录中，get请求的URL能够保存为浏览器的书签 这些都是post请求不能做到的  缓存是get请求被广泛应用的根本原因，除了缓存结果没有其他的多余动作  因此绝大部分的GET请求被CDN缓存起来了  大大减少了Web服务器的负担。

HTTPS

http与https 的区别

http是超文本传输协议 信息是明文传输 存在安全风险的问题  https 能够解决http不安全的缺陷 ，在tcp和http网络层之间加入了 SSL/TLS 安全协议 使得报文能加密传输。
?
http连接建立相对简单，tcp三次握手之后 便可以进行http报文的传输 而https 在tcp三次握手之后 还需要进行 ssl/tls 的握手过程 才能进加密报文传输
HTTP的端口号是80 ，https的端口号是 443
https协议需要向ca 申请数字证书 来保证服务器的身份是可信的。

https 解决了哪些风险

窃听风险，比如通信链路层可以获取通信的内容 用户账号被盗的风险
篡改风险 比如强制进行垃圾广告的植入
冒充风险 冒充淘宝网站 用户金钱损失
?
?
引入了https之后 加入了 SSL、TLS协议 可以很好的解决这些风险
?
信息加密：交互信息无法被窃取
校验机制：无法篡改通信内容 篡改了就不能正常显示
身份证书：能证明网站就是原来的网站
?
ssl tsl 是可以保证通信安全的。

如何理解HTTP的协议是无状态的

  这个无状态的状态值  就是客户端的状态 所以就是字面意思 就是http协议中的 服务端不会保存客户端的任何信息。
  比如当浏览器发送一次请求的时候  服务器响应了  如果这个浏览器发送第二次请求的时候 这个服务器还是会响应  但是不知道的是 你就是刚才那个浏览器
可以利用cookie 和seesion 进行状态的记录

那么Session和Cookie 的区别和联系是什么呢？

cookie就是保存在客户端的 一小块文本串的数据 ? 客户端向服务器发送这个请求的 时候 服务端就向客户端发送一个cookie 客户端就会把cookie 保存起来。在客户端下次向 同一个服务器再次发送请求的时候  cookie 就会被携带发送到 服务器中  服务端就会根据这个cookie来判断用户的身份和状态。
?
Session指的就是服务器和客户端一次会话过程  它是另外一种记录客户状态的机制 不同的是cookie保存在客户端的浏览器中 
而Session则是保存服务器上的 客户端浏览器进行访问的时候 服务器就会客户端的信息 以某种的形式记录在服务器上  那么这个就是Session
客户端进行访问的时候 只需要从这个Session中查找出用户的状态。
?

session和cookie到底有什么不同的地方

存储的位置不一样 Cookie保存在客户端中而Session保存在服务器端 存储的数据类型不一样 cookie只能保存ASCII ，Session可以存储任意的数据类型一般的情况下我们可以在Session中保持一些常用变量的信息比如说Used 有效期不同 cookie可以设置为长时间的保存 Session的保存的时间比较的短。客户端关闭或者session超时的时候都会失效。 隐私策略不同 cookie存储在客户端会比较容易遭到不法的获取早期就会有人将用户名和密码的名字放在cookie中而被别人获取 Session存储在服务器中安全性相对于cookie会高一些

存储大小的不同 单个的cookie保存的数据不能超过 4k Session可存储的数据远远的高于cookie。

Session和cookie有什么关联呢

用户第一次请求服务器的时候服务器会根据用户提交的信息创建相应的Session 请求返回时将此 Session 的唯一标识信息SessionId 返回给浏览器浏览器收到服务器返回的SessionID 信息就会把这个信息存入cookie中同时cookie记录此 SessionID 是属于哪一个域名的。

当用户第二次访问服务器的时候请求就会自动判断此域名下是否存在cookie信息如果存在的话自动将cookie信息也发送给服务端服务端就会从cookie中获取 SessionID 再根据SessionID 查找对应的Session信息如果没有找到的话就说明用户没有登录或者登录的失效如果找到 session的话就说明用户已经登录可以去执行后面的操作了。

分布式的环境下 Session怎样去处理

可以使用 Redis 等的分布式缓存进行存储Session 在多台服务器之间进行共享。

传输层重点协议

负责数据能从发送端传输到发送端

TCP协议

概念：传输控制协议，需要对传输的数据进行详细的控制 Transmission Control Protocol，在传输之前必须建立连接。

TCP协议段格式

源、目的端口：表示数据从那个进程进来到那个进程中去 ? 32位序号 32位确认号 ? 4位TCp报头长度：表示该TCP头部有多少个32位bit；所以TCP头部最大长度是 15*4 =60 ? 6位标志位 ? URG:紧急指针是否有效 ? ACK:确认号是否有效 ? PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走 ? RST：对方要求重新简历连接，把携带RST的标识称为复位报文段 ? SYN:请求建立连接；把携带SYN标识的称为同步报文段 ? FIN：通知对方，本端要关闭了携带FIN标识的为结束报文段 ? 16位窗口大小 ? 16位校验和：发送端填充、CRC校验。接收端校验不通过、则认为数据有问题。此处的检验和包含TCP的头部也包含数据部分 ? 16位紧急指针：标识那一部分数据是紧急的数据

TCP的原理：分为安全和效率

安全机制

确认应答机制

? 每一个ACk 都带有对应的确认序列号，告诉发送者，我已经收到了哪些数据，下一次从哪里开始发。

超时重传机制

? ? ? a发送给b之后，可能因为其他的原因导致数据无法正常到达如果在一个规定的时间段内没有收到确认应答就会进行重发。 ?

? ? ? ? 但是也会因为 ACK的丢失，因此主机b会收到很多的重复数据，只要利用序列号就可以进行去重。 ? 超时的情况怎样确定 ? 最理想的情况就是找到一个最小的时间保证确认应答一定能在这个时间内进行返回 ? 这个时间的长短会随着网络环境的不同而不同，如果超时时间太长就会影响整体的重传效率，而时间太短就会导致频发的发送重复的包 ? TCP为了保证无论在任何的情况下都能比较高效率的通信因此会动态计算这个最大的超时时间 ?

Linux中超时会500ms为一个单位进行控制，每次判定的时间也是500ms的倍数 ? 如果重发一次仍然得不到应答，就会等待 2500ms 进行重传 ? 如果仍得不到应答等待4500ms 进行重传，依次以指数的形式增长 ? 累计到一定的重传次数，TCP会认为网络或主机出现异常会进行强制关闭主机的操作。

连接管理机制

在正常的情况下 TCP 要经过三次握手建立连接，经过四次挥手断开连接

三次握手的过程：

客户端和服务端都处于close状态服务端监听客户端的请求进入listen 状态

客户端发送连接请求，第一次握手 (SYN = 1， seq = x) ,发送完毕之后，客户端就进入了 SYN-sent状态

服务端确认连接第二次握手(syn = 1 ,ack = 1, seq = y ,acknum = x+1),发送完毕之后，服务端就进入了 syn_rcv 状态

客户端收到服务端的确认之后再次向服务端确认这就是第三次握手 (ack = 1 ,acknum = y+1 ),发送完毕之后客户端进入了 established 当服务端接收到这个包的时候进入 established 状态。

TCP的握手为什么是三次？

为啥不能是两次？
1.为了防止服务器端开启一些无用的连接增加服务器的开销
2、防止已经失效的连接接请求报文又突然传送到了服务端 因而产生错误
?
由于网络传输是有延时的（要通过网络的光纤和各种的中间代理服务器）
如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。
?
如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，服务器端是不知道客户端有没有接收到服务器端返回的信息的。
?
服务端就认为这个连接是可用的，端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。这样一来，就会有很多无效的连接端口白白地开着，导致资源的浪费。
还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。
?
为啥不是四次？
因为三次的握手已经可以创建可靠的连接了 没有必要进行再多一次的握手导致花费了更多的时间来建立连接。

在第二次握手的时候传回了ACK为甚还要传回SYN？

ACK是为了告诉客户端传回的数据已经接收无误了。
?
而传回的SYN就是为了告诉客户端服务端的响应的确是客户端发送的报文。

第三次握手的时候可以携带数据吗？

在第三次握手的时候可以进行数据的携带 ?
这个时候的客户端已经是 established的状态了  对于客户端来讲的话 已经建立连接成功了 并且确认服务端的接收和发送能力是正常的。
第一次握手的时候不能发送数据是因为 安全的考虑 因为如果允许携带数据的话  攻击者每次在SYN报文中携带大量的数据的话 就会导致服务器消耗很多的时间和空间来处理这些报文 就会造成CPU的内存消耗。
?
?
?

TCP 的四次挥手过程

?
当数据传输完成之后 通信双方那个都可以主动的断开连接请求，假定是客户端发起的请求
?
?
客户端发送释放连接报文 ?  第一次挥手(FIN = 1 ,seq = u) 发送完毕之后 客户端就会进入 
fin_wait_1 状态
?
服务端发送确认报文 第二次挥手 (ack = 1 ,ack = u+1 ,seq = v) 发送完毕之后 服务端就会进入
close_wait 状态 客户端收到这个确认包之后就会进入 fin_wait_2 状态
?
服务端发送释放连接报文 第三次挥手 (fin = 1, ack = 1 ,seq = w ,ack = u+1)  发送完毕之后服务端进入last_ack 等待来自客户端的最后一个ack
?
?
客户端发送确认报文之后 第四次挥手(ack = 1,seq = u+1 ,ack = w+1) 客户端接收到来自服务端的关闭请求 发送一个确认包 并进入 time_wait 等待某个固定的时间之后(2msl 报文最大生命周期 )
没有收到服务端的ack 认为服务器已经进入了正常的关闭状态  于是自己也进入CLOSED 服务端接收到这个确认包之后进入 CLOSED状态。

在四次挥手的过程中为什么要等地啊2msl 才能进入CLOSED

等待：
为了保证客户端发送最后一个ack报文段可以顺利到达服务端 这个ack报文段 可能会丢失 ，因此处于 LAST_ACK 的服务端就接收不到对已发送的FIN + ACK 报文段的确认 服务端会超时重传这个FIN+ACK报文段 而客户端就能在2MSL时间内（超时+1msl传输）收到这个重传的FIN+ACK
报文段 接着客户端重传一次确认 重新启动 2MSL  计时器 。最后客户端和服务器就会正常进入CLOSED状态。
防止已经失效的连接请求报文段出现在本连接中。客户端在发送完最后的一个请求ACK的时候，在经过2msl 就可以使本连接持续时间内所产生的所有报文段 ? 从网路中消失 就可以使得下一个连接中不会出现这种旧的连接请求的报文段了。

为什么是2msl？

msl是报文的最大生存时间  它是任何报文在网络上存在的最长时间 超过这个时间的话报文就会被丢弃。
网络中可能存在发送方的 数据包 当这些发送方的数据包被接收方处理之后 又会向对方发送响应 所以一来一回需要等待2倍的时间。
?
?
并且此时被动关闭方没有收到 断开连接的最后的ack报文的话 那么就会进行超时重传的机制 这样的来回时间也是刚好 2msl。

服务端状态转化

CLOSED ->  LISTEN  服务器端调用 listen后进入了LISTEN状态  ，等待客户端连接
LISTEn -> SYN_RCVD：一旦监听到连接的请求，就将该链接放入内核等待队列中，并且向客户端发送 SYN确认报文
SYN_RCVD-> ESTABLISHED： 服务端一旦收到 客户端的确认报文 ，就会进入 ESTABLISHED  装态就可以进行读写数据了
ESTABLISHED  -> CLOSED_WAIT： 当客户端主动关闭连接的时候  服务器会收到结束的报文段  服务器返回确认报文并进入 CLOSED_WAIT
CLOSE_WAIT ? -> LAST_ACK: 进入CLOSE——WAIT后就说明服务器准备关闭连接（需要处理完之前的数据）；当服务器真正调用close关闭连接，会向客户端发送FIN，此时的服务器进入了LAST_ACk状态，等待最后一个到来 （这个ACK是客户端确认收到了 FIN）
LAST_ACK -> CLOSED ：服务器收到了对 FIN的ACK，彻底关闭连接

客户端的状态转换

?
CLOSED -> SYN_SENT: 客户端 调用connect，发送同步报文段
SYN _SENT - >  ESTABLISHED: connect 连接成功 ，进入ESTABLISHED 状态 开始读写数据
ESTABLISHED - > FIN_WAIT_1:客户端主动调用  close时，向服务器发送结束报文段 同时进入 FIN_WAIT_1
FIN_WAIT_ 1 - > FIN_WAIT_2：  客户端收到服务器发来对结束报文段的确认 进入TIME_WAIT _2 ,开始等待服务器的结束报文段
FIN_WAIT _2 - > TIME_WAIT：客户端收到服务器发来的结束报文段  ，进入TIME_WAIT ，并发送 LAST_ACK 
TIME _WAIT -> CLOSED :客户端要等待一个2MSL （Max Segment Life,报文最大生存时间）的时间，才会进入CLOSED状态

为什么TIME_WAIT的时间是 2MSL？
    因为TIME_WAIT 持续存在2MSL的话，就能保证 在两个传输 方向上尚未  被接收 或迟到的报文段都已经消失，否则服务器立刻重启的话 可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的
    同时也保证了最后一个报文的可靠到达，假设最后一个ACK丢失  那么服务器再重发一个FIN。这s时虽然客户端 的进程不在了 ，但是TCP连接还在 仍然可以重发 LAST_ACK.

 CLOSE_WAIT
     一般而言得话  对于服务器上出现的 大量CLOSE_WAIT状态，原因就是服务器 没有正确的关闭SOCket，导致了四次挥手没有完成 ，这个是一个bug，只要加上了对应的close就可以解决问题

流量控制

接收端处理数据的速度是有限的，如果发送端发送的太快的话导致接收端的缓冲区被打满，这个时候如果继续发送就会造成丢包继而引起丢包重传的一系列操作

 TCP支持 根据接收端的处理能力 决定发送端的发送速度。这个机制就叫做 流量控制（Flow Control）
                     接收端将自己可以接收的缓冲区大小 放入TCP首部中窗口大小  字段，通过ACK端 通知发送端
                     窗口大小字段越大，说明网路的吞吐量就越大
                     接收端一旦发现自己的缓冲区快满了 就会将窗口大小设置成一个更小的值 通知给发送端
                     发送端 一旦发现自己的缓冲区  块满了，就会将窗口大小设置成一个更小的值 通知给发送端，发送端接受到这个窗口之后  就会减自己的发送速度
                     如果接收端缓冲区满了，就会将窗口设置为0，这时发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

拥塞控制

虽然有滑动窗口这个机制，但是在开始的阶段就发送大量的数据就可能引发问题 TCP引入了慢启动的机制，先发少量的数据，摸清当前的网络状态，再决定按照多大的速度传输数据此处引发的概念就叫做拥塞窗口发送开始的时候，定义拥塞窗口的大小为1，每次收到一个ACK应答的时候拥塞窗口加一，每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小做比较，取得较小的值作为实际发送窗口。

慢启动是初始的速度慢，但是增长的速度很快，为了不增长的那么快，因此不能让拥塞窗口单纯的加倍此处引入一个叫做慢启动阈值，当拥窗口超这个阈值的时候，不再按照指数方式增长，按照线性的方式增长。

当TCP开始启动的时候，慢启动阈值等于窗口的最大值，每次超时重发的时候，慢启动阈值会变为原来的一半，同时拥塞窗口置为1 少量的丢包会引发超时重传，大量的丢包就是网络堵塞，拥塞控制就是TCP尽可能很快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

效率机制

滑动窗口

对于确认应答的策略，对于每一个发送的数据段都要给一个 ACK确认应答，收到ACK之后再发送下一个数据段，这样做的缺点就是性能会比较差，尤其是往返的时间较长的时候。因为这样的效率会比较的低，那么就可以一次发送很多条的数据就可以大大的提升性能（其实就是将多段的等待时间重叠在一起）窗口的大小就是指无需等待确认应答而可以继续发送数据的最大值如图中显示发送四个段的时候不需要等待ack 直接发送。收到第一个ack的时候，滑动窗口向后移动继续发送后面的数据操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区记录当前还有那些数据没应答只有确认应答过的数据才能从缓冲区中删掉窗口越大，那么网络的吞吐率就越高

关于丢包的处理情况

数据包已经抵达，但是ACK丢失

部分的ack丢失不要紧可以通过后续的ack 进行确认。

数据包直接丢失

当某一段报文丢失得时候发送端就会一直收到 1001 这样的ACK ，就是在提醒发送端我想要1001 但是发送端主机连续三次收到了同样的1001 这样的应答就会将对应的数据 1001-2000重新发送这个时候接收端收到1001之后再次返回的就是7001 因为之前的数据已经收到了但是放在了接收缓冲区中 这种机制也被称为高速重发机制也叫做快重传

延迟应答

如果接收数据的主机立刻返回Ack应答那么返回的窗口就会比较小。窗口越大那么吞吐量就会越大，传输的效率就会越高。不是所有的包都可以延时应答数量限制：每隔N个包就应答一次时间限制：超过最大延迟时间就应答一次操作系统不同延时应答的时间也不同

捎带应答

在延迟应答的基础上，很多情况下客户端服务器在应用层也是一发一收那么这个时候 ACK就可以搭顺风车和服务器回应一起返回给客户端。

面向字节流

缓冲区

在创建一个TCP的时候同时会在内核中创建一个发送缓冲区和一个接受缓冲区调用write的时候，数据就会先写入缓冲区中，若发送的字节数太长的话，就会拆分多个TCP数据包发送的字节数太短的话就会现在缓冲区中等待接收的时候，数据也是从网卡驱动中到达内核的接收缓冲区然后应用程序可以调用 read 从接收缓冲区拿数据 TCP的一个连接既有发送缓冲区又有接收缓冲区对于这样的连接亦可以读又可以写这个就是全双工。因为有缓冲区的存在，所以TCP程序的读和写不需要一一匹配

大小限制

粘包问题

包指的是应用层的数据包，在TCP协议中在传输层的角度来看的话 TCP是一个一个的报文过来的，按照序号放在缓冲区中，但是在应用层的角度来看，不知道这样的一串连续的字节数据们不知道一个完整的数据包从哪里开始和结束。解决粘包问题就是需要明确两个包的界限定长的包就每次按照固定大小读取变长的包可以在包头位置约定一个包总长度的字段变长的包还可以在包和包之间使用明确的分隔符。

TCP小结

tcp的复杂性是因为需要保证可靠性同时又要尽可能的提高性能

可靠性

校验和 ? 序列号 ? 确认应答 ? 超时重传 ? 连接管理 ? 流量控制 ? 拥塞控制

提高性能

滑动窗口 ? 快速重传 ? 延迟应答 ? 捎带应答 ? 定时器：超时重传定时器、保活定时器

基于TCP应用层协议

HTTP HTTPS SSH Telnet FTP SMTP

UDP协议

格式：

16位的源端口号和16位的目的端口号 ? 16位的UDP长度、表示整个数据报（UDP首部+UDP数据的最大长度） ? 如果校验和出错就会全部丢弃

特点：传输的过程类似于寄信

无连接

知道对方的IP和端口号就可以直接进行传输，不需要进行连接

不可靠

没有任何安全机制，发送端发送数据之后如果因为网络的故障无法发送到对方 UDP协议层不会给应用层返回任何的错误信息。

面向数据报

应用层交给UDP多长的报文 UDP就会原样进行返回，既不会拆分也不会进行合并

缓冲区

UDP只有接收缓冲区，没有发送缓冲区 ? UDP的Socket既可以读也可以写，这个概念叫做全双工

大小受限制：

UDP协议首部有一个16位的最大长度、也就是说一个UDP能传输的数据最大的长度就是 64k

基于UDP的应用层协议

NFS：网络文件系统 ? TFTP：简单文件传输协议 ? DHCP：动态主机配置协议 ? BOOTP：启动协议（用于无盘设备启动） ? DNS：域名解析协议

扩展的问题

怎样基于UDP实现一个可靠的传输？ UDP的大小是受限制的要给予传输层的UDP设计传输超过64k 的数据应该如何设计 ? 参考TCP可靠性机制在应用层实现的类似逻辑 ? 引入序列号：保证数据的顺序 ? 引入确认应答：确保对方收到了数据 ? 引入超时重传机制，如果超一段时间没有进行应答就重新发送数据

TCP协议和UDP对比

TCP应用于可靠性的传输，应用于文件传输重要的状态更新等场景 ? UDP用于对高速传输和实时性要求较高的通信领域，UDP还可以用于广播 ? 总结就是这两者都是程序员的工具根据适合的场景来使用适合的协议。

网络层重点协议

IP协议（在复杂的网络环境中确定一个合适的路径）

4位版号位：指定Ip协议的版本对于IPV4来说就是4

4位头部长度：Ip头部的长度是多少个32bit，也就是length4的字节数，4bit的最大数字是15，因此IP头部的最大长度就是60字节

8位服务类型（TOS）： 3位优先权字段，4位TOS字段，和一位保留字段、4位TOS分别表示：最小延时、最大吞吐量、最高可靠性、最小成本。这四者相互冲突，只能选择一个，对于ssh这样的应用程序最小延时比较重要、对于ftp这样的程度，最大吞吐量比较重要。

16位总长度：Ip数据报整体占了多少个字节

16位标识：唯一的标识主机发送的报文。如果Ip报文在数据链路层被分片了，那么每一个片内里面的ID都是相同的

3位标志字段：第一位保留（暂时不进行使用、等到需要的时候再进行使用）第二位的位置为1 表示是禁止分片这个时候如果报文的长度超过了MTU、IP模块就会丢弃报文、第三位表示“更多的分片”，如果进行了分片的话，最后的一个位置为1，其他是0，类似于一个结束标志

13位分片偏移：是分片相对于原始IP报文开始处的偏移，其实就是表示当前的分片在源报文中的哪一个位置；实际的偏移字节数是这个值8得到的，因此除了最后一个报文之外，其他的报文长度必须是8的整数倍

8位生存时间（TTL（Time To Live））：数据报到达的目的的最大报文的跳数。一般是64.每次经过一个路由 TTL-=1，一直减到0都没有到达就进行丢弃

8位协议：表示上层协议的类型

16位头部校验和：使用CRC进行校验，来鉴别头文件是否损坏

32位源地址和32位目标地址：表示的是发送端和接收端选项字段（不定长最多有 40字节)

数据链路层重点协议

以太网

概念：以太网不是一种具体的网路而是 一种技术标准 ，既包含了数据链路层的内容，也包含了一些物理层的内容；以太网是当前应用最为广泛的局域网技术。 ? 以太网帧格式 ? ? 原地址和目的地址是指网卡的MAC地址 ? 帧协议类型字段有三种值：IP、ARP、RARP ? 帧末尾是CRC校验码

MTU

概念：

相当于快递的时候对于包裹尺寸的限制。这个限制是不同的数据链路对应的物理层产生的限制。以太网帧中的数据长度规定为最小46字节，最大1500字节、ARP数据包的长度不够46字节，需要进行填充补位 最大值1500称为以太网的最大传输单元（MTU）,不同的网络有不同的MTU。 如果一个数据包从以太网路由到拨号链路上，数据包长度大于拨号链路的MTU，则需要对数据包进行分片不同数据链路层标准的MTU是不同的。

MTu对Ip协议的影响

数据链路层MTU的限制，对于较大的IP数据报就行分包 ? 将较大的IP协议包分成多个小的包 ? 每个小包IP协议头的16位标识都是相同的 ? 每个小包的IP协议头的3位标志字段中，第二位为0，标识允许分片，第三为标识结束标记 ? 到达对端再将小包按照顺序重组，拼装在一起返回给传输层 ? 一旦这些小包中的任意一个丢失，接收端的重组就会失败。但是Ip层不会负责重新传输数据

MTU对于UDP的影响

一旦UDP携带的数据超过了1472 ，那么就会在网络层分成多个IP数据报 ? 这多个的Ip数据报有任意一个丢失，都会引起接收端网络层的重组失败，如果UDP数据报在网络层被分片，整个数据丢失的概率就会增加

MTU对于TCP的影响

TCP的单个数据报的最大消息长度，称为MSS (max segment Size) ? TCP在建立连接的过程中通信双方会进行MSS协商 ? 在最理想的情况下 MSS的值正好是在IP不会被分片处理的最大长度 ? 双发在发送SYN的时候就会在TCP的头写入自己能支持的MSS ? 双方得知之后就会选择较小的MSS值 ? MSS的值就是TCP首部的40字节边长选项中

ARP协议

概念：ARP并不是一个单纯的数据链路层协议，而是一个介于数据链路层和网络层之间的协议

ARP协议的作用

ARP建立了主机的IP地址和MAC地址的映射关系 ? 在网络通信时，源主机的应用程序知道目的主机的IP地址和端口号，却不知道目的主机的硬件地址 ? 数据包首先是被网卡接收到再去处理上层协议的，如果接收到的硬件地址与本机的不符合，则直接会被丢弃 ? 在通讯前必须获得目的主机的硬件地址

ARP协议的工作流程

源主机发出ARP请求，询问 IP地址主机硬件地址是多少，将这个请求在本地网段进行广播 ?

目的主机接收到广播的ARP请求，发现其中的IP地址与本机相符合，则发送一个ARP应答数据包给源主句，将自己的硬件地址填写在应答包中 ? 每台主机都维护一个ARP缓存表， arp -a 查看，缓存表的过期时间一般是 20分钟，如果20分钟没有使用某个表项，那么表项就会失效，下次需要重新发送ARP请求或得目的主机的硬件地址。