目录
4、TCP的三次握手与四次挥手，各个状态名称与含义，TIMEWAIT的作用。
1、计算机网络学习笔记
1、OSI与TCP/IP各层的结构与功能，都有哪些协议？
TCP/IP 5层模型：应用、传输、网络、数据链路、物理
TCP/IP 4层模型：应用、传输、网络、网络接口
各层次对应设备：
网关：应用层、传输层（网关在传输层上以实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关的结构也和路由器类似，不同的是互连层。网关既可以用于广域网互连，也可以用于局域网互连）
路由器：网络层（路由选择、存储转发）
交换机：数据链路层、网络层（识别数据包中的MAC地址信息，根据MAC地址进行转发，并将这些MAC地址与对应的端口记录在自己内部的一个地址表中）
网桥：数据链路层（将两个LAN连起来，根据MAC地址来转发帧）
集线器（Hub）：物理层（纯硬件设备，主要用来连接计算机等网络终端）
中继器：物理层（在比特级别对网络信号进行再生和重定时，从而使得它们能够在网络上传输更长的距离）
各端口对应的服务：
2、TCP和UDP的区别。
TCP即传输控制协议，UDP即用户数据报协议，他们的区别主要有以下几点：
TCP协议是面向连接的，发送数据之前需要建立连接；UDP协议是无连接的，发送数据之前不需要建立连接
TCP协议提供可靠的传输服务；UDP协议提供不可靠的传输服务
TCP发送数据大小会受发送窗口、接收窗口及MSS（最大报文段）限制，因此会分为多段发送；UDP发送数据大小即为数据本身大小
TCP拥有众多反馈机制与附加机制；UDP没有反馈机制
TCP传输速度较慢；UDP传输速度较快
总的来说，TCP协议提供面向连接的，可靠的传输服务，但速度较慢，适合文件下载等传输任务；UDP协议提供无连接的，不可靠的传输服务，但速度较快，适合媒体流等看重传输速度的传输任务。
3、TCP报文结构。
其中：
Source port：源端口，16位，说明发送端的端口号
Destination port：目的端口，16位，说明接收端的端口号
Sequence number：序列号，32位，说明这个数据的序号，从而接收端接收后可以进行排序，避免接收错序
Acknowledgement number：确认号，ACK，32位，表示说明这是对哪个数据的确认，表明期待接收编号为x的数据段，小于x的数据段已经成功接收并交给了上层
TCP header length：TCP头部长度，4位，由于TCP头部中带有option，而option的长度不固定，因此需要标识头部的长度
0（灰色那段）：padding，6位，无实际作用
标志位：6位，作用分别如下：
URG：说明数据部分是否有紧急数据，可能导致乱序问题，因此并不会在实际中被使用
ACK：说明确认号是否有效
PSH：告诉接收方将缓冲区的数据尽快交给上层，可能会导致数据丢失，因此不会在实际中被使用
RST：重置连接，将连接强制中断
SYN：同步标识，建立连接时使用
FIN：结束标识，关闭连接时使用
Window size：窗口大小，16位，发送端告诉接收端自己的发送窗口的缓冲区大小
Checksum：校验和，16位
Urgent pointer：紧急数据指针，16位，说明数据段中哪一段数据是紧急数据
Options：0或32位，选项部分
Data：数据部分
4、TCP的三次握手与四次挥手，各个状态名称与含义，TIMEWAIT的作用。
各个状态的意义如下：
LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；
三次握手，TCP建立连接的过程：
1、客户机发起请求，客户端进入SYN_SEND状态，等待服务器端确认。
- SYN为1：说明发起新的连接
- SEQ为x：说明这个段的序列号是多少，服务器收到后会调整接收的滑动窗口为x+1(表明下一次要接收的段的序列号为x+1)，一般随机选取x
- 指定窗口大小的值：客户机说明自己的接收窗口目前还可容纳多少数据
2、服务器响应请求，服务器端进入SYN_RECV状态。
- ACK为1：表示确认接收请求
- ACK号为x+1：表示接受了序列号位x及以下的数据，期待序列号为x+1的数据
- SYN为1：说明服务器同意新的连接建立(只是同意，还没有没有分配端口资源)
- SEQ为y：说明这个段的序列号是多少，客户机收到后会调整接收的滑动窗口为y+1(表明下一次要接收的段的序列号为y+1)，与x没有关系
- 指定窗口大小的值：服务器说明自己的接收窗口目前还可容纳多少数据
3、服务器响应请求，客户端和服务器端进入ESTABLISHED状态。
- ACK为1：表示确认接收请求
- ACK号为y+1：表示接受了序列号位y及以下的数据，期待序列号为y+1的数据
- SEQ为x+1：说明这个段的序列号是多少，服务器收到后会调整接收的滑动窗口为x+2(表明下一次要接收的段的序列号为x+2)
为什么需要三次握手呢？一次握手，两次握手为什么不行呢？
原因如下：
一次握手：客户机根本不知道连接的有效性
- 有可能这次握手请求根本没有到达服务器或者直接被服务器拒绝。
两次握手：服务器无法确认该请求的合法性，如果是两次握手服务器将立即分配端口资源造成资源浪费，可能使得其它客户机无法连接
- 发送方请求连接的包在信道里面停留了很长时间，使得连接都释放掉了这个包才到
- 会遭遇SYN泛洪攻击：一台恶意的主机伪造自己的IP向服务器请求连接
四次挥手，TCP释放连接的过程：
1、释放连接的发起方发起释放连接请求
- FIN为1：结束位为1，说明发起方的发送过程已经结束，不会再向对方发送实际数据
- SEQ为x：序列号为x
2、释放连接的接收方回复释放连接请求
- ACK为1：表示确认接收请求
- ACK号为x+1：表示接受了序列号位x及以下的数据，期待序列号为x+1的数据
3、释放连接的接收方同意释放连接请求
- FIN为1：结束位为1，说明发起方的发送过程已经结束，不会再向对方发送实际数据
- SEQ为y：序列号为y
4、释放连接的发起方回复释放连接请求
- ACK为1：表示确认接收请求
- ACK号为y+1：表示接受了序列号位x及以下的数据，期待序列号为y+1的数据
四次挥手中第二次是否可以去掉？
不能, 如果去掉第2次挥手。试想有一种情况，当Client发送了FIN报文给Server，而Server这时候还想传递一些信息给客户端，如果没有第二次握手，Server这时候直接发送剩下的数据，那客户端怎么知道Server是否收到了自己发送的关闭请求呢？如果Client知道Server接收到了自己发送的关闭报文，那Client可以大胆的接收Server发送的剩余数据，因为它知道Server不会消耗太多的时间在剩余数据上。如果Client不知道Server有没有真正收到的关闭报文，那它自己难免会忐忑，自己在接收Server传递的剩余数据的同时，要不要再次发送新的关闭报文呢？亦或者一直等待Server端的ACK，那万一Server端没有收到FIN，也不会发送ACK，那是强制关闭还是一直等待呢？
TIMEWAIT:
发起方在第四次握手发出ACK后会等待一段时间后再正式释放连接，这段时间被称为TIME_WAIT。会有TIME_WAIT的原因主要是保证接收方能够收到对于FIN的ACK，如果ACK在返回的过程中丢失会导致接收方超时，这时会再发一个FIN给到发起方，因此这一段时间正好是ACK返回时间加上重发的FIN到达发起方的时间。另一个原因是如果没有TIME_WAIT就马上建立了新的连接，那么网络中遗留下来的旧的数据包将可能会干扰接收方的接收，接收方无法识别出是新的数据包还是旧的数据包，因此在TIME_WAIT接收到的其它数据包会被丢弃。
5、TCP阻塞控制。
由于发送方到接收方之间的信道是公用的，因此如果发送方不考虑中间信道的容量随意发送就可能出现拥塞，拥塞会导致延迟严重，甚至大量丢包，因此我们需要进行拥塞控制。
拥塞控制的关键在于控制发送端的发送速率，发送端的发送速率受到发送窗口大小的限制，因此在TCP的拥塞控制中实际控制的是发送端的发送窗口大小。
当出现以下两种情况之一时，我们断定传输出现了拥塞：
- 连续(三个)的序号为x的ACK：说明序号为x的TCP数据段很可能丢失
- 超时时间到来前未收到ACK
当出现拥塞时，我们主要有以下方法进行拥塞控制：
AIMD（additive increase multiplicative decrease）：
意思即加性增加乘性减少，其初始阻塞窗口大小为任意值。
当我们每成功传输一个TCP数据段，拥塞窗口大小加1MSS（最大报文大小），此为加性增加；而当我们发现传输出现拥塞时，拥塞窗口大小减半，此为乘性减少。
这种算法的问题在于增加的速度慢，丢包代价大。
慢启动：
慢启动的初始时拥塞窗口大小为1MSS（因此叫慢启动算法），最大为65535MSS（窗口大小只有16bit，因此最大也只能这么大）。慢启动算法开始时每成功传输一个TCP数据段，拥塞窗开大小也是增加1MSS，但当其发现拥塞时，会首先确定一个阙值：阙值为当前窗口大小的一半，然后根据不同的机制进行处理：
Tahoe机制：
出现拥塞时窗口大小会变回1MSS，但当窗口大小小于阙值时，传输成功窗口大小加倍（指数增长），大于阙值后改为加性增长。
Reno机制：
出现拥塞窗口大小直接变为阙值。（也称为快速恢复机制）
6、TCP滑动窗口与回退N指针协议。
滑动窗口协议：
- 发送端和接收端分别设定发送窗口和接收窗口。
- 三次握手的时候，客户端把自己的缓冲区大小也就是窗口大小发送给服务器，服务器回应是也将窗口大小发送给客户端，服务器客户端都知道了彼此的窗口大小。
- 比如主机A的发送窗口大小为5，主机A可以向主机B发送5个单元，如果B缓冲区满了，A就要等待B确认才能继续发送数据。
- 如果B缓冲区中有1个报文被进程读取，主机B就会回复ACK给主机A，接收窗口向前滑动，报文中窗口大小为1，就说明A还可以发送1个单元的数据，发送窗口向前滑动，之后等待主机B的确认报文。
只有接收窗口向前滑动并发送了确认时，发送窗口才能向前滑动。
1、比特滑动窗口协议
上面说的只是滑动窗口协议的理论，实际应用中又有不同。首先就是停等协议(stop－and－wait)，这时接受方的窗口和发送方的窗口大小都是1，1个比特就够表示了，所以也叫1比特滑动窗口协议。发送方这时自然发送每次只能发送一个，并且必须等待这个数据包的ACK，才能发送下一个。虽然在效率上比较低，带宽利用率明显较低，不过在网络环境较差，或是带宽本身很低的情况下，还是适用的。
2、后退N帧协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议，这里发送的窗口大小为n，接受方的窗口仍然为1。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
例子：
假设n=9：首先发送方一口气发送10个数据帧，前面两个帧正确返回了，数据帧2出现了错误，这时发送方被迫重新发送2-8这7个帧，接受方也必须丢弃之前接受的2-8这几个帧。 后退n协议的好处无疑是提高了效率，但是一旦网络情况糟糕，则会导致大量数据重发，反而不如上面的停等协议，实际上这是很常见的。
3、选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。重传协议便是用来解决这个问题。原理也很简单，接收端总会缓存所有收到的帧，当某个帧出现错误时，只会要求重传这一个帧，只有当某个序号后的所有帧都正确收到后，才会一起提交给高层应用。重传协议的缺点在于接受端需要更多的缓存。
7、HTTP的报文结构。
Http协议（Hypertext Transfer Protocol）即超文本传输协议，它是一个应用层的基于TCP的无状态的协议，一般的通信过程为：建立连接、发送请求、响应请求、释放连接。其报文结构分为请求头与响应头两种：
请求头：
请求头的第一行为请求行，其包括了三部分重要内容：
1、请求方法：主要为Get、Post等方法
2、URL：即请求的地址
3、协议版本：主要有Http1.0和Http1.1两种
4、请求头接下来是请求头部（也叫头域），头域的长度是不固定的，每一个头域属性的格式为：字段名：值（如：Range：请求范围）
5、头域下面是一行空行，表示头域的结束。
6、空行下来就是请求要提交的数据。
响应头：
与请求头类似，响应头的第一行为响应行，主要包含如下三部分内容：
1、版本：使用的Http协议版本
2、状态码：表示处理结果状态的数值，由三位数字组成，第一位数字表示响应的类型，主要有以下几种：
- 1XX：表示服务器已接收了客户端请求，客户端可继续发送请求
- 2XX：表示服务器已成功接收到请求并进行处理
- 3XX：表示服务器要求客户端重定向
- 4XX：表示客户端的请求有非法内容
- 5XX：表示服务器未能正常处理客户端的请求而出现意外错误
3、原因短语：一串用于解释返回该状态码原因的字符串
4、响应行下来是响应头域，与请求头类似。
5、响应头域下来是一行空行表示响应头域的结束。
6、最后是响应头的响应实体内容。
8、HTTP的状态码含义。
状态码位于响应头的响应行中，表示服务器处理结果的情况，由三位数字组成，第一位数字表示响应的类型，主要有以下几种：
1、1XX：表示服务器已接收了客户端请求，客户端可继续发送请求
100 (Continue/继续)
如果服务器收到头信息中带有100-continue的请求，这是指客户端询问是否可以在后续的请求中发送附件。在这种情况下，服务器用100允许客户端继续或用417 (Expectation Failed)告诉客户端不同意接受附件。这个状态码是 HTTP 1.1中新加入的。
101 (Switching Protocols/转换协议)
101 状态码是指服务器将按照其上的头信息变为一个不同的协议。这是 HTTP 1.1中新加入的。
2、2XX：表示服务器已成功接收到请求并进行处理
200 (OK/正常)
200 的意思是一切正常。一般用于相应GET和POST请求。
201 (Created/已创建)
201表示服务器在请求的响应中建立了新文档；应在定位头信息中给出它的URL。
202 (Accepted/接受)
202告诉客户端请求正在被执行，但还没有处理完。
203 (Non-Authoritative Information/非官方信息)
状态码203是表示文档被正常的返回，但是由于正在使用的是文档副本所以某些响应头信息可能不正确。这是 HTTP 1.1中新加入的。
204 (No Content/无内容)
在并没有新文档的情况下，204确保浏览器继续显示先前的文档。这各状态码对于用户周期性的重载某一页非常有用，并且你可以确定先前的页面是否已经更新。但是，这种方法对通过刷新响应头信息或等价的HTML标记自动重载的页面起作用，因为它会返回一个204状态码停止以后的重载。但基于JavaScript脚本的自动重载在这种情况下仍然需要能够起作用。
205 (Reset Content/重置内容)
重置内容205的意思是虽然没有新文档但浏览器要重置文档显示。这个状态码用于强迫浏览器清除表单域。这是 HTTP 1.1中新加入的。
206 (Partial Content/局部内容)
206是在服务器完成了一个包含Range头信息的局部请求时被发送的。这是 HTTP 1.1中新加入的。
3、3XX：表示服务器要求客户端重定向
300 (Multiple Choices/多重选择)
300表示被请求的文档可以在多个地方找到，并将在返回的文档中列出来。如果服务器有首选设置，首选项将会被列于定位响应头信息中。
301 (Moved Permanently)
301状态是指所请求的文档在别的地方；文档新的URL会在定位响应头信息中给出。浏览器会自动连接到新的URL。
302 (Found/找到)
与301有些类似，只是定位头信息中所给的URL应被理解为临时交换地址而不是永久的。注意：在 HTTP 1.0中，消息是临时移动(Moved Temporarily)的而不是被找到。
303 (See Other/参见其他信息)
这个状态码和 301、302 相似，只是如果最初的请求是 POST，那么新文档（在定位头信息中给出）药用 GET 找回。这个状态码是新加入 HTTP 1.1中的。
304 (Not Modified/为修正)
当客户端有一个缓存的文档，通过提供一个 If-Modified-Since 头信息可指出客户端只希望文档在指定日期之后有所修改时才会重载此文档，用这种方式可以进行有条件的请求。304是指缓冲的版本已经被更新并且客户端应刷新文档。另外，服务器将返回请求的文档及状态码 200。
305 (Use Proxy/使用代理)
305表示所请求的文档要通过定位头信息中的代理服务器获得。这个状态码是新加入 HTTP 1.1中的。
307 (Temporary Redirect/临时重定向)
浏览器处理307状态的规则与302相同。307状态被加入到 HTTP 1.1中是由于许多浏览器在收到302响应时即使是原始消息为POST的情况下仍然执行了错误的转向。只有在收到303响应时才假定浏览器会在POST请求时重定向。添加这个新的状态码的目的很明确：在响应为303时按照GET和POST请求转向；而在307响应时则按照GET请求转向而不是POST请求。该状态码是新加入HTTP 1.1中的。
4、4XX：表示客户端的请求有非法内容
400 (Bad Request/错误请求)
400指出客户端请求中的语法错误。
401 (Unauthorized/未授权)
401表示客户端在授权头信息中没有有效的身份信息时访问受到密码保护的页面。这个响应必须包含一个WWW-Authenticate的授权信息头。
403 (Forbidden/禁止)
403的意思是除非拥有授权否则服务器拒绝提供所请求的资源。这个状态经常会由于服务器上的损坏文件或目录许可而引起。
404 (Not Found/未找到)
404状态每个网络程序员可能都遇到过，他告诉客户端所给的地址无法找到任何资源。它是表示“没有所访问页面”的标准方式。
405 (Method Not Allowed/方法未允许)
405指出请求方法(GET, POST, HEAD, PUT, DELETE, 等)对某些特定的资源不允许使用。该状态码是新加入 HTTP 1.1中的。
406 (Not Acceptable/无法访问)
406表示请求资源的MIME类型与客户端中Accept头信息中指定的类型不一致。406是新加入 HTTP 1.1中的。
407 (Proxy Authentication Required/代理服务器认证要求)
407与401状态有些相似，只是这个状态用于代理服务器。该状态指出客户端必须通过代理服务器的认证。代理服务器返回一个Proxy-Authenticate响应头信息给客户端，这会引起客户端使用带有Proxy-Authorization请求的头信息重新连接。该状态码是新加入 HTTP 1.1中的。
408 (Request Timeout/请求超时)
408是指服务端等待客户端发送请求的时间过长。该状态码是新加入 HTTP 1.1中的。
409 (Conflict/冲突)
该状态通常与PUT请求一同使用，409状态常被用于试图上传版本不正确的文件时。该状态码是新加入 HTTP 1.1中的。
410 (Gone/已经不存在)
410告诉客户端所请求的文档已经不存在并且没有更新的地址。410状态不同于404，410是在指导文档已被移走的情况下使用，而404则用于未知原因的无法访问。该状态码是新加入 HTTP 1.1中的。
411 (Length Required/需要数据长度)
411表示服务器不能处理请求（假设为带有附件的POST请求），除非客户端发送Content-Length头信息指出发送给服务器的数据的大小。该状态是新加入 HTTP 1.1的。
412 (Precondition Failed/先决条件错误)
412状态指出请求头信息中的某些先决条件是错误的。该状态是新加入 HTTP 1.1的。
413 (Request Entity Too Large/请求实体过大)
413告诉客户端现在所请求的文档比服务器现在想要处理的要大。如果服务器认为能够过一段时间处理，则会包含一个Retry-After的响应头信息。该状态是新加入 HTTP 1.1的。
414 (Request URI Too Long/请求URI过长)
414状态用于在URI过长的情况时。这里所指的“URI”是指URL中主机、域名及端口号之后的内容。该状态是新加入 HTTP 1.1的。
415 (Unsupported Media Type/不支持的媒体格式)
415意味着请求所带的附件的格式类型服务器不知道如何处理。该状态是新加入 HTTP 1.1的。
416 (Requested Range Not Satisfiable/请求范围无法满足)
416表示客户端包含了一个服务器无法满足的Range头信息的请求。该状态是新加入 HTTP 1.1的。
417 (Expectation Failed/期望失败)
如果服务器得到一个带有100-continue值的Expect请求头信息，这是指客户端正在询问是否可以在后面的请求中发送附件。在这种情况下，服务器也会用该状态(417)告诉浏览器服务器不接收该附件或用100状态告诉客户端可以继续发送附件。该状态是新加入 HTTP 1.1的。
5、5XX：表示服务器未能正常处理客户端的请求而出现意外错误
500 (Internal Server Error/内部服务器错误)
500是常用的“服务器错误”状态。
501 (Not Implemented/未实现)
501状态告诉客户端服务器不支持请求中要求的功能。例如，客户端执行了如PUT这样的服务器并不支持的命令。
502 (Bad Gateway/错误的网关)
502被用于充当代理或网关的服务器；该状态指出接收服务器接收到远端服务器的错误响应。
503 (Service Unavailable/服务无法获得)
状态码503表示服务器由于在维护或已经超载而无法响应。
504 (Gateway Timeout/网关超时)
该状态也用于充当代理或网关的服务器；它指出接收服务器没有从远端服务器得到及时的响应。该状态是新加入 HTTP 1.1的。
505 (HTTP Version Not Supported/不支持的 HTTP 版本)
505状态码是说服务器并不支持在请求中所标明 HTTP 版本。该状态是新加入 HTTP 1.1的。
9、HTTP Request的几种类型。
在Http中主要包含以下请求方法：
GET： 请求指定的页面信息，并返回实体主体
HEAD： 只请求页面的首部。
POST： 请求服务器接受所指定的文档作为对所标识的URI的新的从属实体
PUT： 从客户端向服务器传送的数据取代指定的文档的内容
DELETE： 请求服务器删除指定的页面
OPTIONS： 允许客户端查看服务器的性能
TRACE： 请求服务器在响应中的实体主体部分返回所得到的内容
PATCH： 实体中包含一个表，表中说明与该URI所表示的原内容的区别
MOVE： 请求服务器将指定的页面移至另一个网络地址
COPY： 请求服务器将指定的页面拷贝至另一个网络地址
LINK： 请求服务器建立链接关系
UNLINK： 断开链接关系
WRAPPED： 允许客户端发送经过封装的请求
CONNECT：用于动态切换到隧道的代理
其中Http1.0仅支持GET、HEAD和POST，其余方法均为Http1.1添加。值的注意的是：GET方法与POST方法类似，但GET方法参数写在URL上，POST参数写在请求实体内容中，且GET方法参数不大于1024Byte，POST则没有限制。
10、HTTP1.1与HTTP1.0的区别。
Http1.0与Http1.1主要有以下区别：
- 是否允许复用连接：Http1.0不允许，响应请求后就断开连接，Http1.1允许且默认开启连接复用
- Host头域：Http1.0没有，Http1.1有
- 状态码：Http1.1比Http1.0多了100,101（转换协议）,203（非官方信息）,205（重置内容）等状态码
- 请求方式：Http1.0只有GET、HEAD和POST方法，Http1.1新增了其他多种方法
11、HTTP怎么处理长连接。
长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接（一个TCP连接通道多个读写通信）。
心跳包：
- 检测长连接的重要技术手段。
- 可以由服务器发送：定时向客户端发送小数据，根据回执判断客户端是否在线。
- 也可由客户端发送：定时向服务器发送小数据，报告客户端当前在线。
Http协议是一个短连接、无状态的基于TCP的协议，默认的流程是：建立连接-->发送请求-->响应请求-->断开连接。
在Http1.1中加入了保持长连接的功能，可以通过Http头域属性Connection:keep-alive开启。
另外，我们也可以使用Http轮询来模拟长连接的过程。
Http长轮询：
http 长轮询是server 收到请求后如果有数据，立刻响应请求；如果没有数据 就会停留一段时间，这段时间内，如果 server 请求的数据到达（如查询数据库或数据的逻辑处理完成），就会立刻响应；如果这段时间过后，还没有数据到达，则以空数据的形式响应http请求；若浏览器收到的数据为空，会再次发送同样的http请求到server；
缺点：
server 没有数据到达时，http连接会停留一段时间，这会造成服务器资源浪费；
短轮询：
http 短轮询是 server 收到请求 不管是否有数据到达都直接响应http 请求；如果浏览器收到的数据为空，则隔一段时间，浏览器又会发送相同的http请求到server 以获取数据响应；
缺点：
消息交互的实时性较低（server端到浏览器端的数据反馈效率低）
异同点：
相同点：
当server 的数据不可达时，基于http长轮询和短轮询 的http请求，都会 停留一段时间；
不同点：
http长轮询是在服务器端的停留，而http 短轮询是在 浏览器端的停留；
性能总结：
不管是长轮询还是短轮询，都不太适用于客户端数量太多的情况，因为每个服务器所能承载的TCP连接数是有上限的，这种轮询很容易把连接数顶满；
12、Cookie和Session的作用与原理。
由于Http协议是一种短连接的、无状态的协议，因此如果我们一般无法获取客户端以前的请求信息与状态信息。
为了解决这个问题，保存请求的状态，Cookie和Session出现了。简单来说，Cookie存于客户端，而Session存于服务器，它们都保存和用户历史请求相关的信息。在发送Http请求时Cookie或SessionId会随被加入请求参数中一起发给服务器，服务器根据Cookie的信息或SessionId查找到的Session信息来得知客户端的状态信息，进而进行进一步的相关操作。
Cookie
- cookie被存储于客户端
- cookie在RFC（请求注释）有定义
- 与cookie相关的头域参数有cookie和set-cookie
Session
- session被存储与服务器
- session并没有在Http协议中有明确的定义
- session通过sessionId来区分不同的用户
- 与cookie相比，存储在服务器的session显得更为安全
- session通常的实现方法有两种：
（1）通过cookie实现，在cookie中存储sessionId
（2）回写URL实现，在网页的连接中加入sessionId
13、电脑上访问一个网页，整个过程是怎样的？
- 我们在浏览器中输入网址，但电脑并不认识如此复杂的字符串，因此电脑使用DNS服务解析出对应的IP地址
- 访问网页的过程基于Http协议，因此我们访问网页的过程实际上就是Http协议发送请求和响应请求的过程
- Http协议是应用层协议，它基于传输层的TCP协议，TCP协议描述了进程与进程间如何通信交流，把具体的传输过程交给下层的网络层
- 网络层由IP协议控制数据包的路由选择和存储转发，但由于网络上的主机太多，IP协议管理不过来，因此又把网络主机分为多块，在外部使用EGP外部网关协议，在内部使用IGP内部网关协议（包括RIP协议（路由信息协议内部）与OSPF协议（开放式最短路径优先外部））
- 当网络层的数据传输到以太网后，就通过ARP协议获取目标主机的MAC地址，最后把数据传输的任务交给数据链路层处理
14、Ping的整个过程。ICMP协议是什么？
ICMP即Internet Control Message Protocol，网络控制报文协议，是一个网络层的用于在IP主机、路由器之间传递控制消息的协议。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
其中Ping是ICMP协议中的指令之一，其主要作用的是检查网络的连通情况和检测网络的速度。
Ping的过程主要有如下步骤：
- 检查本地ARP缓存，查找目标主机的MAC地址
- 如果没有找到MAC地址，使用ARP协议获取目标主机MAC地址，并放入ARP缓存
- 发出ICMP echo request包，接收ICMP echo reply包
15、C/S模式下使用Socket通信，几个关键函数。
对于Java Socket编程而言，有两个概念，一个是Server-Socket(port)，一个是Socket（ip，port）。服务端和客户端之间通过Socket建立连接，之后它们就可以进行通信了。首先ServerSocket将在服务端监听某个端口，当发现客户端有Socket来试图连接它时，它会accept该Socket的连接请求，同时在服务端建立一个对应的Socket与之进行通信。这样就有两个Socket了，客户端和服务端各一个。
对于Socket之间的通信其实很简单，服务端往Socket的输出流里面写东西，客户端就可以通过Socket的输入流读取对应的内容。Socket与Socket之间是双向连通的，所以客户端也可以往对应的Socket输出流里面写东西，然后服务端对应的Socket的输入流就可以读出对应的内容。
16、IP地址分类。
IP地址分为IPv4地址（32位）和IPv6地址（128位），在此我们讨论IPv4地址。
IP地址由两部分（网络部分和主机部分）组成，可以分为有类网和无类网两类。
有类网：
有类网分为以下5种：
- A类网：第一位为0，后7位为网络号，剩余24位为主机号，10.0.0.0~10.255.255.255 即10.0.0.0/8。
- B类网：前两位为10，后14位为网络号，剩余16位为主机号，172.16.0.0~172.31.255.255即172.16.0.0/12。
- C类网：前三位为110，后21位为网络号，剩余8位为主机号，192.168.0.0~192.168.255.255 即192.168.0.0/16。
- D类网（不可用）：前四位为1110，后28位为多播地址。
- E类网（不可用）：前四位为1111，被保留。
除了D类网与E类网不能使用外，A、B和C类网IP均可用来表示一台主机。我们一般根据自己网络中主机的多少来选择A、B还是C类网，但一般而言网路中的主机数目都不会刚好等于有类网提供的主机数，于是经常会造成有多余的IP地址浪费，因此我们有了无类网。
无类网：
无类网加入了子网掩码的概念。子网掩码是一个32位地址，用于将某个IP地址划分成网络地址和主机地址两部分。在子网掩码中我们以1表示为网络号，例：255.255.255.0表示前24位为网络号。
17、路由器和交换机的区别。
路由器工作于网络模型的网络层，其主要的功能是路由选择与存储转发，路由器上还能开启ACL访问控制列表（报文过滤器）、NAT地址转换等功能，扩展网络应用。
交换机工作于网络模型的数据链路层，其主要的功能是泛洪、存储转发、过滤和自学习，交换机还能够隔离冲突域，并划分VLAN。
18、各种协议介绍。
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查询失败。
RARP：
作用是完成硬件地址到IP地址的映射，主要用于无盘工作站，因为给无盘工作站配置的IP地址不能保存。工作流程：在网络中配置一台RARP服务器，里面保存着IP地址和MAC地址的映射关系，当无盘工作站启动后，就封装一个RARP数据包，里面有其MAC地址，然后广播到网络上去，当服务器收到请求包后，就查找对应的MAC地址的IP地址装入响应报文中发回给请求者。因为需要广播请求报文，因此RARP只能用于具有广播能力的网络。
TFTP：是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。
HTTP： 超文本传输协议，是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。
NAT：网络地址转换属接入广域网(WAN)技术，是一种将私有（保留）地址转化为合法IP地址的转换技术。
DHCP：动态主机配置协议，是一种让系统得以连接到网络上，并获取所需要的配置参数手段，使用UDP协议工作。具体用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段。
19、DNS域名系统，及其工作原理。
什么是DNS：
一种组织成域层次结构的计算机和网络命名系统，它用于TCP/IP网络，他所提供的服务是用于将主机名和域名转换为IP地址的工作。它基于UDP服务，端口53。该应用一般不直接为用户使用，而是为其他应用服务，如HTTP，SMTP等在其中需要完成主机名到IP地址的转换。
DNS数据库中的名称形成一个分层树状结构称为域命名空间。域名包含单个标签分割点。例如：www.qq.com.。
DNS域名空间的组织方式：
DNS服务的工作过程：
当 DNS 客户机需要查询程序中使用的名称时，它会查询本地DNS 服务器来解析该名称。客户机发送的每条查询消息都包括3条信息，以指定服务器应回答的问题。
- 指定DNS域名，表示为完全合格的域名（FQDN）；
- 指定查询的类型，它可根据类型指定资源记录，或作为查询操作的专门类型。
- DNS域名的指定类型，对于DNS服务器，它始终指定为Internet类别。
DNS递归解析基本流程：
- 客户端向本地名称服务器发出DNS域名请求。
- 本地名称服务器收到请求后，先查询本地的缓存，如果有该域名的记录项，则本地名称服务器就直接把查询的结果返回给客户端；如果没有，则本地服务器再以DNS客户端的角色发送与前面一样的DNS域名查询请求发给根名称服务器。
- 根名称服务器收到DNS请求后，把所查询得到的所请求的DNS域名中顶级域名所对应的顶级域名服务器地址返回给本地名称服务器。
- 本地名称服务器根据根名称服务器返回的顶级名称服务器地址，向对应的顶级名称服务器发送与前面一样的DNS域名查询请求。
- 对应的顶级名称服务器在收到DNS查询请求后，也是先查询自己的缓存，如果有所请求的DNS域名的记录项，则相接把对应的记录项返回给本地名称服务器，然后再由本地名称服务器返回给DNS客户端，否则向本地名称服务器返回所请求的DNS域名中的二级域名所对应的二级名称服务器地址。
- 然后本地名称服务器继续按照前面介绍的方法一次次地向三级、四级名称服务器查询，直到最终的对应域名所在区域的权威名称服务器返回到最终的记录给本地名称服务器。然后再由本地名称服务器返回给DNS客户，同时本地名称服务器会缓存本次查询得到的记录项。
DNS迭代解析基本流程：
- 客户端向本地名称服务器发出DNS域名请求。
- 本地名称服务器收到请求后，先查询本地的缓存，如果有该域名的记录项，则本地名称服务器就直接把查询的结果返回给客户端；如果本地缓存中没有该域名的记录，则向DNS客户端返回一条DNS应答报文，报文中会给出一些参考信息，如本地名称服务器上的根名称服务器地址等。
- DNS客户端在收到本地名称服务器的应答报文后，会根据其中的根名称服务器地址信息，向对应的根名称服务器再次发出与前面一样的DNS查询请求报文。
- 根名称服务器在收到DNS查询请求报文后，通过查询自己的DNS数据库得到请求DNS域名中顶级域名所对应的顶级名称服务器信息，然后以一条DNS应答报文返回给DNS客户端。
- DNS客户端根据来自根名称服务器应答报文中的对应顶级名称服务器地址信息，向该顶级名称服务器发出与前面一样的DNS查询请求报文。
- 顶级名称服务器在收到DNS查询请求后，先查询自己的缓存，如果有所请求的DNS域名的记录项，则相接把对应的记录项返回给DNS客户端，否则通过查询后把对应域名中二级域名所对应的二级名称服务器地址信息以一条DNS应答报文返回给DNS客户端。
- 然后DNS客户端继续按照前面介绍的方法一次次地向三级、四级名称服务器查询，直到最终的权威名称服务器返回到最终的记录。
迭代查询：
本地域名服务器向根域名服务器的查询通常是采用迭代查询。当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么返回给本地域名服务器所要查询的IP地址，要么返回给本地域名服务器下一步应当查询的域名服务器的IP地址。
举个栗子：假设的主机想知道另一个主机（域名为 my.xxsilence.net)的IP地址。具体步骤如下：
① 主机先向其本地域名服务器进行递归查询，如果缓存中没有，继续下一步。
② 本地域名服务器采用迭代查询，先向一个根域名服务器查询。
③ 根域名服务器告诉本地域名服务器，下一次查询的顶级域名服务器 dns.net。
④ 本地域名服务器向顶级域名服务器 dns.net。
⑤ 顶级域名服务器 dns.net，下一次应查询的权限域名服务器dns.xxsilence.net的IP地址。
⑥ 本地域名服务器向权限域名服务器dns.xxsilence.net进行查询。
⑦ 权限域名服务器dns.xxsilence.net告诉本地域名服务器，所查询的主机的IP地址。
⑧ 本地域名服务器最后把查询结果告诉主机。
20、HTTP和HTTPS的区别。
- HTTPS需要用到CA申请证书
- HTTP是超文本传输协议，信息是明文的；HTTPS则是具有安全性的SSL加密传输协议
- HTTP是80,HTTPS是443
- HTTP的连接很简单，是无状态的，HTTPS是HTTP+SSL协议构建的，可进行加密传输、身份认证的网络协议，比HTTP协议安全
21、HTTPS为什么是安全的，具体实现。
在应用层和传输层之间加上了安全层，通过SSL/TLS协议（握手协议）实现。
SSL/TLS协议简目的：
- 所有信息都是加密传播，第三方无法窃听。
- 具有校验机制，一旦被篡改，通信双方会立刻发现。
- 配备身份证书，防止身份被冒充。
SSL/TLS协议简要过程：
- 客户端生成对称密钥；
- 服务器生成非对称加密算法的公钥和私钥；
- 服务器将公钥交给CA机构，申请数字证书；
- 服务器将数字证书发送给客户端，证明公钥不是伪造的；
- 客户端和服务器通过对称密钥加解密后续传输的数据。
解决的问题：
- 数字证书验证公钥是否可信，只要证书可信，公钥就可信。
- 对称加密速度快用于加密数据；公钥加密速度慢，但是安全，用于管理和分配对称密钥。