计算机网络

1.HTTP是什么？有哪些方法？返回状态码？

HTTP（超文本传输协议）是一个基于请求与响应模式的、无状态的应用层协议，常基于TCP的连接方式。

HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

常用的HTTP方法有以下几种

GET： GET方法用来请求URL指定的资源。指定的资源经服务器端解析后返回响应内容。
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。

常见的HTTP相应状态码

返回的状态

• 1xx：指示信息—表示请求已接收，继续处理
• 2xx：成功--表示请求已被成功接收、理解、接受
• 3xx：重定向—要完成请求必须进行更进一步的操作
• 4xx：客户端错误—请求有语法错误或请求无法实现
• 5xx：服务器端错误--服务器未能实现合法的请求

具体的一些错误码如下：

• 200：请求被正常处理
• 204：请求被受理但没有资源可以返回
• 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
• 301：永久性重定向
• 302：临时重定向
• 303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
• 304：发送附带条件的请求时，条件不满足时返回，与重定向无关
• 307：临时重定向，与302类似，只是强制要求使用POST方法
• 400：请求报文语法有误，服务器无法识别
• 401：请求需要认证
• 403：请求的对应资源禁止被访问
• 404：服务器无法找到对应资源
• 500：服务器内部错误
• 503：服务器正忙

补充问题：GET方法与POST方法的区别

区别一：get重点在从服务器上获取资源，post重点在向服务器发送数据；
区别二：get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用”?”连接，多个请求数据间用”&”连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；**(明文传输)**
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；（密文传输）
区别三：Get传输的数据量小，因为受URL长度限制，但效率较高；Post可以传输大量数据，所以上传文件时只能用Post方式；
区别四：get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；post较get安全性较高；
区别五：get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。post支持标准字符集，可以正确传递中文字符

2.HTTP报头格式？如何解析HTTP报头？

请求报文包含三部分：

• a、请求行：包含请求方法、URI、HTTP版本信息
• b、请求头
• c、请求内容实体

Accept：请求报文可通过一个“Accept”报文头属性告诉服务端 客户端接受什么类型的响应。        如Accept:text/plain表示客户端能够接受的响应类型仅为纯文本数据。
Cookie：客户端的Cookie就是通过这个报文头属性传给服务端的。
Referer：表示这个请求是从哪个URL过来的
Cache-Control：对缓存进行控制

响应报文包含三部分：

• a、状态行：包含HTTP版本、状态码、状态码的原因短语
• b、响应头
• c、响应内容实体

Cache-Control：响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。 
如Cache-Control: max-age=3600  让客户端对响应内容缓存3600秒，也即在3600秒内，如果客户再次访问该资源，直接从客户端的缓存中返回内容给客户，不要再从服务端获取。当然，这个功能是靠客户端实现的，服务端只是通过这个属性提示客户端“应该这么做”，做不做，还是决定于客户端，如果是自己宣称支持HTTP的客户端，则就应该这样实现。
Set-Cookie：服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的。

补充问题：URI和URL的区别

URI

URI：统一资源标识符，用来唯一的标识一个资源。Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来唯一表示的。
URI组成：①访问资源的命名机制②存放资源的主机名③资源自身的名称，由路径表示，着重强调于资源。
URL（平常说的“网址”）

URL：Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。

URL组成：①协议(或称为服务方式)②存有该资源的主机IP地址(有时也包括端口号)③主机资源的具体地址。如目录和文件名等 每个URL都是 URI，但不一定每个URI都是URL。这是因为URI还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。

URI和URL都定义了资源是什么，但URL还定义了该如何访问资源。URL是一种具体的URI，它是URI的一个子集，它不仅唯一标识资源，而且还提供了定位该资源 的信息。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，因此它不能是相对的。 在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。相反的是，URL类可以打开一个到达资源的流。

HTTP优缺点（特点）

简单、灵活、易于扩展；

无状态：

        不需要额外的资源来记录状态信息，不仅实现上会简单一些，而且还能减轻服务器的负担，能够把更多的CPU和内存用来对外提供服务；
        没有状态的差异，所以可以很容易的组成集群，**让负载均衡把请求转发到任意一台服务器，不会因为状态不一致导致出错，**使用”堆机器“的”笨方法“轻松**实现高并发高可用**。
         缺点：无法支持需要**连续多个步骤的”事务“操作**。连续的操作每次都得问一遍身份信息，比较麻烦而且增加了不必要的数据传输量 ， **如果需要解决就是cookie。**

明文、： 可以方便调试 ，但 信息会被暴露出来，每一个环节没有隐私可言 。

不安全

HTTP性能

不算差但不够好 。HTTP采用的是”请求-应答“的通信模式，所以性能的关键就在这两点上。

现在的互联网是移动和高并发，不能保证稳定的链接质量，所以在TCP层面上HTTP协议有时候就会表现得不够好。

”请求-应答“模式则加剧了HTTP性能的问题，这就是著名的”队头阻塞（Head-of-line blocking）“，当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。

HTTPS

  超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

 为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS和HTTP的主要区别
1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

3.三次握手过程是什么？第三条丢了会怎样？有什么现象？

背景知识回顾

传输控制协议TCP特点

TCP是一种面向连接（连接导向）的、可靠的基于字节流的传输层通信协议。TCP将用户数据打包成报文段，它发送后启动一个定时器，另一端收到的数据进行确认、对失序的数据重新排序、丢弃重复数据。

TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种端点我们叫作套接字（socket），将端口号拼接到IP地址即构成了套接字，例如 192.1.1.6:50030

基本特点如下：

• 面向连接的、可靠的、基于字节流的 传输层 通信协议
• 将应用层的数据流分割成文段并发送给目标节点的TCP层
• 数据包都有序号，对方收到则发送ACK确认，未收到则重传
• 使用校验和来检验数据在传输过程中是否有误

TCP报文头分析

• 源端口（Source Port）/ 目的端口（Destination Port）
  他们各占2个字节，标示该段报文来自哪里（源端口）以及要传给哪个上层协议或应用程序（目的端口）。

进行tcp通信时，一般client是通过系统自动选择的临时端口号，而服务器一般是使用知名服务端口号或者自己指定的端口号（比如DNS协议对应端口53，HTTP协议对应80）

• 序号（Sequence Number）
  占据四个字节，TCP是面向字节流的，TCP连接中传送的字节流中的每个字节都按顺序编号，例如如一段报文的序号字段值是107，而携带的数据共有100个字段，如果有下一个报文过来，那么序号就从207（100+107）开始，整个要传送的字节流的起始序号必须要在连接建立时设置。首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号
• 确认序号（Acknowledgment Number）
  4个字节，是期望收到对方下一个报文段的第一个数据字节的序号，若确认号=N，则表明：到序号N-1为止的所有数据都已正确收到。例如：B收到A发送过来的报文，其序列号字段是301，而数据长度是200字节，这表明了B正确的收到了A到序号500（301+200-1）为止的数据，因此B希望收到A的下一个数据序号是501，于是B在发送给A的确认报文段中，会把ACK确认号设置为501
• 数据偏移（Offset）

4个字节，指出TCP报文段的数据起始处距离报文段的起始处有多远，这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。单位是32位字，也就是4字节，4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节

• 保留（Reserved）
  6个字节，保留域
• TCP Flags
  控制位，由八个标志位组成，每个标志位表示控制的功能，我们主要来介绍TCP Flags中常用的六个：
• URG（紧急指针标志）：当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。例如，已经发送了很长的一个程序在主机上运行。但后来发现了一些问题，需要取消该程序的运行。因此用户从键盘发出中断命令。如果不使用紧急数据，那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了许多时间
• ACK（确认序号标志）：当ACK=1时确认号字段有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置1
• PSH（push标志）：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP就可以使用推送操作。这时，发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后向上交付
• RST（重置连接标志）：TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接，可以用来拒绝一个非法的报文段或拒绝打开一个连接
• SYN（同步序号，用于建立连接过程）：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在相应的报文段中使用SYN=1和ACK=1。因此，SYN置为1就表示这是一个连接请求或连接接受报文。
• FIN（finish标志，用于释放连接）：当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接
• 窗口（Window）
  是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口（Receiver Window，RWND）。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样就可以控制发送数据的速度。
• 检验和（Checksum）
  检验范围包括首部和数据两部分，由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。这也是TCP可靠传输的一个重要保障
• 紧急指针（Urgent Pointer）
  紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为零时也可发送紧急数据。
• TCP可选项（TCP Options）
  长度可变，最长可达40字节。当没有使用“选项”时，TCP的首部长度是20字节。

TCP的三次握手

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

• 第一次握手： 要建立连接时，客户端发送SYN同步序列编号=1的请求报文包（syn=j）到服务器，并进入SYN_SEND状态，等待服务器确认。（SYN=1,不携带数据，消耗一个序列号）
• 第二次握手： 服务器收到 SYN 包，必须确认客户的 SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；（确认对方序号，选择自己的序号；SYN=1，ACK=1,不携带数据，消耗一个序列号）
• 第三次握手： 客户端收到服务器的SYN + ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。 （若携带数据则消耗序号）

（若果第三步的ACK+SYN包分开发则变成了四次握手）

为什么客户端A最后还要发送一次确认呢?

这主要是为了防止已失效的连接请求报文段突然又传送到了服务器B，因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B,没有“已失效的连接请求报文段”。

现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用报文握手，那么只要B发出确认，新的连接就建立了。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样自白浪费了。

而采用三次报文握手就可避免这样的情况；

为什么需要三次握手才能建立连接(总觉得课本上解释的更好一点)

为了初始化Sequence Number 的初始值，实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认 。

首次握手的隐患——SYN超时

问题起因分析：

• 服务器收到客户端的SYN，回复SYN和ACK的时候未收到ACK确认
• 服务器不断重试直至超时，Linux默认等待63秒才断开连接；（重复5次【不包括第一次】，从1秒开始，每次重试都翻倍:1+2+4+8+16+32=63秒）

针对SYN Flood的防护措施：

• SYN队列满后，通过tcp_syncookies参数会发SYN cookie【源端口+目标端口+时间戳组成】
• 若为正常连接则Client会回发SYN Cookie，直接建立连接；

保活机制：当我们建立连接后，Client出现故障怎么办？

• 向对方发送保活探测报文，如果未收到相应则继续发送；
• 尝试次数达到保活探测数仍未收到相应则中断连接；

4.TCP连接中的三次握手和四次挥手，四次挥手的最后一个ack的作用是什么，为什么要time wait，为什么是2msl？

四次挥手

所谓四次挥手（Four-Way Wavehand）即终止TCP连接，指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，**收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据**，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

• 第一次挥手： Client发送一个连接释放报文段，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。（FIN=1，序号为已发生数据的最后序号+1；可收不可发）
• 第二次挥手： Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。（确认对方并选择自己的序号，自己的序号为自己已发送数据的最后一个序号）
• 第三次挥手： Server发送一个连接释放报文段，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
• 第四次挥手： Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手 。

但是此时连接还没有断掉，得等待时间等待计时器设置的2MSL后A才进入CLOSE阶段。

为什么会有TIME_WAIT状态

客户端连接在收到服务器的结束报文段之后，不会直接进入CLOSED状态，而是转移到TIME_WAIT状态。在这个状态，客户端连接要等待一段长为2MSL，即两倍的报文段最大生存时间，才能完全关闭，其原因主要有两点：

• 确保有足够的时间放对方收到ACK包

客户端A发送的最后一个ACK报文有可能在传输过程中丢失，这样服务器B就收不到确认报文而重新给客户端A发送FIN+ACK报文段。A在等待2MSL时间过程中又收到B发送的FIN+ACK报文段，就会再次发送确认报文给B，重新计时2MSL，就能确保双方都能正常关闭连接。

• 避免新旧连接混淆

就是在三次握手中介绍的“已经失效的报文重新复活”。

为什么需要四次握手才能断开连接

因为TCP连接是全双工的网络协议，允许同时通信的双方同时进行数据的收发，同样也允许收发两个方向的连接被独立关闭，以避免client数据发送完毕，向server发送FIN关闭连接，而server还有发送到client的数据没有发送完毕的情况。所以关闭TCP连接需要进行四次握手，每次关闭一个方向上的连接需要FIN和ACK两次握手，发送发和接收方都需要FIN报文和ACK报文。

服务器出现大量CLOSE_WAIT状态的原因

是由于对方关闭socket连接，我方忙于读或写，没有及时关闭连接

当客户端因为某种原因先于服务端发出了FIN信号，就会导致服务端被动关闭，若服务端不主动关闭socket发FIN给Client，此时服务端Socket会处于CLOSE_WAIT状态（而不是LAST_ACK状态）。通常来说，一个CLOSE_WAIT会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导致系统造成一堆CLOSE_WAIT消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。

解决方法：

检查代码，特别是释放资源的代码
查配置，特别是处理请求的线程配置

5、 DNS域名解析过程

步骤一：当在浏览器中输入域名按下回车键后，浏览器会检查缓存中有没有这个域名对应的解析过的IP地址。如果缓存有，解析结束。

浏览器缓存域名在大小和时间上都是有限制的。缓存时间可由TTL属性来设置缓存时间太长太短都不好，太长，会导致IP解析有变化，会导致域名不能正常解析，部分用户无法访问网站。缓存时间太短，用户每次都需要重新解析一次域名。

步骤二：如果用户的浏览器中缓存没有，浏览器会查找操作系统中是否有这个域名对应的DNS解析结果。

其实操作系统中也会有一个域名解析的过程，在windows中可以通过c:\windows\system32\drivers\etc\hosts文件来设置，你可以将任何域名解析到任何能够访问的IP地址。（黑客劫持域名）步骤一和步骤二都是由本机完成的。

步骤三：当机无法完成域名解析，就会真正请求域名服务器来解析这个域名了。

我们怎样知道域名服务器？网络配置中都会有“DNS服务器地址”操作系统会把这个域名发送到设置中的LDNS，也就是本地的域名服务器。DNS通常都会提供给你本地互联网接入的一个DNS服务器。比如你在学校，那么这个DNS服务器一定在你们学校。WIndows中可由ipconfig查询这个地址。

步骤四：如果LDNS仍然没有解析到，就直接到Root Service域名解析器请求解析

步骤五：根域名服务器返回给本地域名服务器一个所查询余的主域名服务器（gTLDServer）地址。gTLD是国际顶级域名服务器，如：.com/.cn/.org等，全球只有13台左右。

步骤六：本地域名服务器（Local DNS Server）再向上一步返回的gTLD服务器发送请求

步骤七：接收请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server通常就是你注册的域名服务器（如你的域名供应商）

步骤八：Name Server域名服务器会查询存储的域名和IP的映射关系表，正常情况下都根据域名得到目标IP记录，连同一个TTL值返回给DNS Server域名服务器

步骤九：返回该域名对应的IP和TTL值，Local DNS Server会缓存这个域名和IP的对应关系，缓存的时间有TTL值控制。

步骤十：把解析的结果返回给用户，用户根据TTL值缓存在本地系统缓存中，域名解析过程结束。

6、 OSI，TCP/IP，五层协议的体系结构，以及各层协议

答:OSI分层 （7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
TCP/IP分层（4层）：网络接口层、 网际层、运输层、 应用层。
五层协议 （5层）：物理层、数据链路层、网络层、运输层、 应用层。
每一层的协议如下：
物理层：CLOCK、IEEE802.2 （中继器，集线器）
数据链路：PPP、FR、HDLC、VLAN、MAC （网桥，交换机）
网络层：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）
传输层：TCP、UDP、SPX
会话层：NFS、SQL、NETBIOS、RPC
表示层：JPEG、MPEG、ASII
应用层：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS
每一层的作用如下：
物理层：通过媒介传输比特,确定机械及电气规范（比特Bit）
数据链路层：将比特组装成帧和点到点的传递（帧Frame）
网络层：负责数据包从源到宿的传递和网际互连（包PackeT）
传输层：提供端到端的可靠报文传递和错误恢复（段Segment）
会话层：建立、管理和终止会话（会话协议数据单元SPDU）
表示层：对数据进行翻译、加密和压缩（表示协议数据单元PPDU）
应用层：允许访问OSI环境的手段（应用协议数据单元APDU）

7、 IP地址的分类

答:

A类地址：以0开头， 第一个字节范围：1~126（1.0.0.0 - 126.255.255.255）；

B类地址：以10开头， 第一个字节范围：128~191（128.0.0.0 - 191.255.255.255）；

C类地址：以110开头， 第一个字节范围：192~223（192.0.0.0 - 223.255.255.255）；

D类地址：以1110开头，第一个字节范围：224~239（224.0.0.0 - 239.255.255.255）；（作为多播使用）

E类地址：保留

其中A、B、C是基本类，D、E类作为多播和保留使用。

以下是留用的内部私有地址：

A类 10.0.0.0—10.255.255.255

B类 172.16.0.0—172.31.255.255

C类 192.168.0.0—192.168.255.255

IP地址与子网掩码相与得到网络号：

ip : 192.168.2.110

&

Submask : 255.255.255.0

网络号 ：192.168.2 .0

注:

主机号，全为0的是网络号（例如：192.168.2.0），主机号全为1的为广播地址（192.168.2.255）

ARP是地址解析协议，简单语言解释一下工作原理。

答:1：首先，每个主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系。
2：当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，该数据包包括的内容有：源主机 IP地址，源主机MAC地址，目的主机的IP 地址。
3：当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想要找的MAC地址。
4：源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表，并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。
广播发送ARP请求，单播发送ARP响应。