1.OSI参考模型和TCP/IP模型

OSI分层（7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

TCP/IP分层（4层）：网络接口层、网际层、运输层、应用层。

五层协议（5层）：物理层、数据链路层、网络层、运输层、应用层。

每一层的作用：

物理层：在物理媒体上透明地传输原始比特流（比特Bit）

数据链路层：检测并校正物理层传输介质上产生的传输差错，加强物理层传输原始比特流的功能，使链路对网络层显现为一条无差错、可靠的数据传输线路（帧Frame）

网络层：把网络层的协议数据单元（分组）从源端传到目的端，为分组交换网上的不同主机提供通信服务。其关键问题是对分组进行路由选择，并实现流量控制、拥塞控制、差错控制和网际互联等功能（包Packet）

传输层：为高层用户提供可靠的、透明的、有效的数据传输服务，实现端到端（进程到进程）的数据传输管理、差错控制、流量控制和复用管理（段Segment）

会话层：建立、管理和终止会话（会话协议数据单元SPDU）

表示层：主要用于处理在两个通信系统中交换信息的表示方式。数据压缩、加密和解密是表示层可提供的数据表示交换功能（表示协议数据单元PPDU）

应用层：为特定类型的网络应用提供访问OSI环境的手段（应用协议数据单元APDU）

2.OSI参考模型和TCP/IP模型的比较

共同点：

1）两者都以协议栈的概念为基础，并且协议中的协议彼此独立。

2）两个模型中都采用分层的体系结构，且各个层的功能也大体相似。

3）两个模型都可以解决异构网络的互联，实现不同厂家生产的计算机之间的通信。

不同点：

1）对于OSI/RM模型有三个明确的核心概念：服务、接口、协议，而TCP/IP对此没有明确的区分。

2）OSI/RM模型是在协议发明之前设计的，而TCP/IP是在协议出现之后设计的。

3）一个更大的区别在于OSI/RM模型有7层，TCP/IP只有4层。

4）OSI/RM的网络层同时支持无连接和面向连接的通信，但是在传输层上只支持面向连接的通信。而TCP/IP模型的网络层上只有一种无连接通信，但是在传输层上同时支持两种通信模式。

3.TCP对应的协议和UDP对应的协议

TCP对应的协议：

（1）FTP：定义了文件传输协议，使用21端口（控制连接）和20端口（数据连接）。

（2）Telnet：简单远程终端协议，使用23端口。

（3）SMTP：简单邮件传输协议，用于发送邮件。服务器开放的是25号端口。

（4）POP3：邮局协议，它是和SMTP对应，POP3用于接收邮件，所用的是110端口。

（5）HTTP：超文本传输协议，HTTP协议定义了浏览器怎样向万维网服务器请求文档，以及服务器怎样把文档传送给浏览器。默认是80端口。

UDP对应的协议：

（1）DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。

（2）SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

（3）TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

4.域名解析过程

1）客户机向其本地域名服务器发出DNS请求报文。

2）本地域名服务器收到请求后，查询本地缓存，假设没有该记录，则以DNS客户的身份向根域名服务器发出解析请求。

3）根域名服务器收到请求后，判断该域名属于.com域，将对应的顶级域名服务器dns.com的IP地址返回给本地域名服务器。

4）本地域名服务器向顶级域名服务器dns.com发出解析请求报文。

5）顶级域名服务器dns.com收到请求后，判断该域名属于abc.com域，故将对应的授权域名服务器dns.abc.com的IP地址返回给本地域名服务器。

6）本地域名服务器向授权域名服务器dns.abc.com发起解析请求报文。

7）授权域名服务器dns.abc.com收到请求后，将查询结构返回给本地域名服务器。

8）本地域名服务器将查询结果保存到本地缓存，同时返回给客户机。

5.在浏览器中输入www.baidu.com后执行的全部过程

（1）输入网址

（2）浏览器向DNS请求解析

（3）DNS将这个域名解析成IP地址，浏览器根据IP地址找到对应的服务器

（4）浏览器与该服务器建立TCP连接

（5）浏览器给web服务器发送一个HTTP请求

（6）服务器接收到get请求，然后处理并返回一个响应

（7）TCP连接释放

（8）浏览器将文件进行解析，并将web页显示给用户

6.HTTP中GET和POST的区别

HTTP是一个应用层协议，主要用于Web开发，通常由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如“HTTP/1.1 200

OK”，以及返回的内容，如请求的文件、错误消息或者其它信息。HTTP的设计目的是保证客户机与服务器之间的通信。HTTP的工作方式是客户机与服务器之间的请求-应答协议。

HTTP特点

1）无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后即断开连接。采用这种方式可以节省传输时间。

2）无状态：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP请求由三部分组成，分别是：请求行、消息报头、请求正文。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文。

HTTP中的GET、POST、PUT、DELETE就对应着对这个资源的查、改、增、删4个操作。我们最常见的就是GET和POST了。

在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET和POST。

ØGET -从指定的资源请求数据。

ØPOST -向指定的资源提交要被处理的数据

GET方法

请注意，查询字符串（名称/值对）是在GET请求的URL中发送的：

/test/demo_form.asp?name1=value1&name2=value2

POST方法

请注意，查询字符串（名称/值对）是在POST请求的HTTP消息主体中发送的：

POST /test/demo_form.asp HTTP/1.1

Host: w3schools.com

name1=value1&name2=value2

GET和POST区别

ØGET在浏览器回退时是无害的，而POST会再次提交请求。

ØGET产生的URL地址可收藏为书签，而POST不可以。

ØGET请求会被浏览器主动cache，而POST不会，除非手动设置。

ØGET请求只能进行url编码，而POST支持多种编码方式。

ØGET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

ØGET请求在URL中传送的参数是有长度限制的，而POST没有。

Ø对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

ØGET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

ØGET参数通过URL传递，POST放在Request body中。

HTTP协议的底层是TCP/IP协议，所以GET、POST都是TCP连接。从技术上将，GET能做的事情，POST一样也能做到。GET产生一个TCP数据包，而POST产生两个TCP数据包。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟，POST需要汽车跑两趟。

HTTP请求头

accept：浏览器通过这个头告诉服务器，它所支持的数据类型。如：text/html image/jpeg

accept-Charset：浏览器通过这个头告诉服务器，它支持哪种字符集。

accept-encoding：浏览器通过这个头告诉服务器，它支持哪种压缩格式。

accept-language：浏览器通过这个头告诉服务器，它的语言环境。

host：浏览器通过这个头告诉服务器，它想访问哪台主机。

if-modified-since：浏览器通过这个头告诉服务器，资源的缓存时间。

referer：浏览器通过这个头告诉服务器，客户机是哪个页面来的(防盗链)。

Connection：浏览器通过这个头告诉服务器，请求完后是断开链接还是维持链接。

HTTP响应头

location：服务器通过这个头告诉浏览器跳到哪里。

server：服务器通过这个头告诉浏览器服务器的型号。

content-encoding：服务器通过这个头告诉浏览器数据的压缩格式。

content-length：服务器通过这个头告诉浏览器回送数据的长度。

content-language：服务器通过这个头告诉浏览器语言环境。

content-type：服务器通过这个头告诉浏览器回送数据的类型。

refresh：服务器通过这个头告诉浏览器定时刷新。

content-disposition：服务器通过这个头告诉浏览器以下载方式打开数据。

transfer-encoding：服务器通过这个头告诉浏览器数据是以分块方式回送的

以下三个表示服务器通过这个头告诉浏览器不要缓存

expires：-1

cache-control：no-cache

pragma：no-cache

7.HTTP1.0和HTTP1.1

请求一个文档所需的时间是该文档的传输时间加上两倍往返时间RTT（一个RTT用于连接TCP连接，另一个RTT用于请求和接收文档）。

HTTP/1.0的主要缺点，就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象需要依次进行链接，那么每一次链接下载都导致2RTT的开销。另一种开销就是客户和服务器为每一次建立新的TCP连接都要分配缓存和变量。

HTTP/1.1协议很好地解决了这个问题，它使用了持续连接。所谓持续连接就是服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。

HTTP/1.1协议的持续连接有两种工作方式：非流水线方式和流水线方式。

非流水线方式：是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接的两倍RTT的开销节省了建立TCP连接所需的一个RTT时间。但非流水线方式还是优缺点的，因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。

流水线方式：是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水方式时，客户访问所有的对象只需花费一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档效率。

8.HTTP状态码

状态码分类

1XX-信息，接受的请求正在处理

2XX-成功，操作被成功接收并处理

3XX-重定向，需要进一步的操作以完成请求

4XX-客户端错误，请求包含语法错误或无法完成请求

5XX-服务器错误，服务器在处理请求的过程中发生了错误。

常见状态码

200 -请求成功

301 -资源（网页等）被永久转移到其它URL

404 -请求的资源（网页等）不存在

500-内部服务器错误

9.Session和Cookie总结

Session和cookie都是http协议的一个补充。http协议是无状态的，http请求完成就结束了，服务端需要区分上次请求和下次请求是否有关联关系就没法做。为了实现类似功能，就有了session和cookie。session是浏览器首次访问一个网站时分配了一个sessionid，这个sessionid就是cookie的一个值，在浏览器打开期间，每次请求都会带上这个值，这就解决了浏览器无法区分上次请求与下次请求的关联关系。session有个问题不能解决，那就是浏览器关掉再打开就没有了，没法解决比如记住登录状态这类问题，普通设置了过期时间的cookie可以解决这类问题，设置好过期时间就OK了。

10.Session的实现原理和应用场景

Session机制

Session机制是一种服务器端的机制。当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识，称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用，如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

Session实现

1）使用Cookie来实现

服务器给每个Session分配一个唯一的JSESSIONID，并通过Cookie发送给客户端。当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。

2）使用URL回写来实现

URL回写是指服务器在发送给浏览器页面的所有链接中都携带JSESSIONID的参数，这样客户端点击任何一个链接都会把JSESSIONID带会服务器。如果直接在浏览器输入服务端资源的url来请求该资源，那么Session是匹配不到的。Tomcat对Session的实现是一开始同时使用Cookie和URL回写机制，如果发现客户端支持Cookie，就继续使用Cookie，停止使用URL回写。如果发现Cookie被禁用，就一直使用URL回写。

应用场景

Session典型的场景比如购物车，当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识。

11.Cookie的原理和应用场景

Cookie就是浏览器储存在客户端上的一小段文本文件。cookie是纯文本格式，不包含任何可执行的代码。一个Web页面或服务器告知浏览器按照一定规范来储存这些信息，并在随后的请求中将这些信息发送至服务器，Web服务器就可以使用这些信息来识别不同的用户。大多数需要登录的网站在用户验证成功之后都会设置一个cookie，只要这个cookie存在并可以，用户就可以自由浏览这个网站的任意页面。

Cookie应用场景

1）自动登录

2）用户喜好，个性化服务，推荐

12.Session和Cookie的区别，如何实现共享Session

Session和Cookie的作用都是为了保持访问用户和后端服务器的交互状态。

区别：

（1）Cookie保存在客户端浏览器中，而Session保存在服务器上

（2）客户端对每个网站所能缓存的Cookie个数、大小都有限制，客户端可以禁用Cookie。

（3）Cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗，考虑到安全应当使用session。

（4）Session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用Cookie。

如何共享Session

1）写客户端Cookie的方式

当用户登陆成功以后，把网站域名、用户名、密码、token、session有效时间全部采用cookie的形式写入到客户端的cookie里面，如果用户从一台Web服务器跨越到另一台服务器的时候，我们的程序主动去检测客户端的cookie信息进行判断，然后提供对应的服务，当然，如果cookie过期或者无效，自然就不让用户继续服务了。

1）服务器之间Session数据同步的方式

假设Web服务器A是所有用户登陆的服务器，那么当用户验证登陆一下，session数据就会写到A服务器里，那么就可以自己写脚本或者守护进程来自动把session数据同步到其他Web服务器，那么当用户跳转到其他服务器的时候，那么session数据是一致的，自然就能够直接进行服务无须再次登陆了。缺点是可能会速度慢，不稳定，如果是单向同步的话，登陆服务器出现问题，那么其他服务器也无法服务，当然也可以考虑双向同步的问题。这个方案都可以解决，目前zookeeper可以实现。

2）利用NFS共享Session数据的方式

其实这个方案和下面的Mysql方案类似，只是存储方式不一样。大致就是有一台公共的NFS服务器（Network File Server）做共享服务器，所有的Web服务器登陆的时候把session数据写到这台服务器上，那么所有的session数据其实都是保存在这台NFS服务器上的，不论用户访问哪台Web服务器，都要来这台服务器获取session数据，那么就能够实现共享session数据了。缺点是依赖性太强，如果NFS服务器down掉了，那么大家都无法工作了，当然，可以考虑多台NFS服务器同步的形式。这个方案都可以解决，目前zookeeper可以实现，当然memcached也可以实现session共享。

4）利用Mysql数据库共享Session数据的方式

这个方式与NFS的方式类似，也是采用一台Mysql服务器做共享服务器，把所有的session的数据保存到Mysql服务器上，所有Web服务器都来这台Mysql服务器来获取Session数据。缺点也是依赖性太强，Mysql无法工作了影响所有的Web服务器，当然，可以考虑多台Mysql数据库来共享session，使用同步Mysql数据的方式。这种方式跟方式3类似，同样可以采用memcached来做，nosql也可以实现，这些都不是问题。

5）使用硬件设备

这个算是比较成熟的解决方案了，使用类似BIG-IP的负载设备来实现资源共享，那么就能够又稳定又合理的共享Session了。目前很多门户网站采用这种方式。缺点很明显了，就是要收费了，硬件设备肯定需要购买成本的，不过对于专业或者大型应用来讲，是比较合理并且值得的，这种方式可以放到最后面考虑。

13.TCP三次握手和四次挥手的全过程

三次握手

Step1：客户机的TCP首先向服务器TCP发送一个连接请求报文段。这个特殊的报文段不含应用层数据，其首部中SYN（同步位）标志位被置为1。另外，客户机会随机选择一个起始序号seq=x（连接请求报文不携带数据，但要消耗掉一个序号）。

Step2：服务器的TCP收到连接请求报文段后，如同意建立连接，就向客户端发回确认，并为该TCP连接分配TCP缓存和变量。在确认报文段中，SYN和ACK（确认位）位都被置为1，确认号字段的值为x+1，并且服务器随机产生起始序号seq=y。确认报文段同样不包含应用层数据。

Step3：当客户机收到确认报文段后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置为1，序号字段为x+1，确认号字段为y+1。

SYN洪泛（syn flood）攻击

假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。

四次挥手

Step1：客户机打算关闭连接，就向其TCP发送一个连接释放报文段，并停止再发送数据，主动关闭TCP连接，该报文段的FIN（终止位）标志位被置为1，seq=u，它等于前面已发送过的数据的最后一个字节的序号加1。

Step2：服务器收到连接释放报文段后即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于前面已发送过的数据的最后一个字节的序号加1。此时，从客户端到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接受，即从服务器到客户机这个方向的连接并未关闭。

Step3：若服务器已经没有要向客户机发送的数据，就通知TCP释放连接，此时其发出FIN=1的连接释放报文段。

Step4：客户机收到连接释放报文段后，必须发出确认。在确认报文段中，ACK字段被置为1，确认号ack=w+1，序号seq=u+1。此时TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入到连接关闭状态。

为什么不采用“三次握手”释放连接，且发送最后一次握手报文后要等待2MSL（最大报文段寿命，Maximum Segment

Lifetime）的时间呢？

原因有两个：

1）为了保证A发送的最后一个确认报文段能够到达B。如果A不等待2MSL，若A返回的最后确认报文段丢失，则B不能进入正常关闭状态，而A此时已经关闭，也不可能重传。

2）防止出现“已失效的连接请求报文段”。A在发送完最后一个确认报文段后，再经过2MSL可保证本连接持续的时间内所产生的所有报文段从网络中消失。

为什么不采用“两次握手”建立连接

这主要是为了防止两次握手情况下已失效的连接请求报文段突然又传送到服务端，而产生错误。考虑下面这种情况：客户A向服务器B发出TCP连接请求，第一个连接请求报文在网络的某个节点长时间滞留，A超时后认为报文丢失，于是再重传一次连接连接请求，B收到后建立连接。数据传输完毕后双方断开连接。而此时，前一个滞留在网络中的连接请求到达了服务端B，而B认为A又发来连接请求，此时若是使用“三次握手”，则B向A返回确认报文段，由于是一个失效的请求，因此A不予理睬，建立连接失败。若采用的是“两次握手”，则这种情况下B认为传输连接已经建立，并一直等待A传输数据，而A此时并无连接请求，因此不予理睬，这样就造成了B的资源白白浪费了。

为什么“四次挥手”

试想一下，假如现在你是客户端你想断开跟Server的所有连接该怎么做？第一步，你自己先停止向Server端发送数据，并等待Server的回复。但事情还没有完，虽然你自身不往Server发送数据了，但是因为你们之前已经建立好平等的连接了，所以此时他也有主动权向你发送数据，故Server端还得终止主动向你发送数据，并等待你的确认。其实，说白了就是保证双方的一个合约的完整执行！

TCP如何识别不同的请求

每个连接建立时，都会保存一个唯一的套接字（主机IP地址+端口号），有了这个套接字，你就知道对方的IP地址、端口号等信息。这样，通过这个套接字，就可以向指定方发送信息了。

14.TCP和UDP的区别和适用场景

区别

1）TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的

2）TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。

3）TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。

4）TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率

5）TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。

6）TCP面向的是字节流的服务，UDP面向的是报文的服务。

7）TCP传输慢，UDP传输快；因为TCP需要建立连接、保证可靠性和有序性，所以比较耗时。这就是为什么视频流、广播电视、在线多媒体游戏等选择使用UDP。

为什么TCP比UDP可靠

1）TCP是面向有连接的，建立连接之后才发送数据；而UDP则不管对方存不存在都会发送数据。

2）TCP有确认机制，接收端每收到一个正确包都会回应给发送端。超时或者数据包不完整的话发送端会重传。UDP没有，因此可能丢包。

什么时候使用TCP

当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。

什么时候应该使用UDP

当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，实时性好，这时就可以使用UDP。比如：DNS、TFTP和SNMP。

15.TCP流量控制

流量控制的基本方法是由接收方控制发送方发送数据的速率。常见的方式有两种：停止-等待协议和滑动窗口协议。

1）停止-等待协议

发送方每发送一帧，都要等待接收方的应答信号，之后才能发送下一帧；接收方每接受一帧，都要反馈一个应答信号，表示可接受下一帧，如果接收方不反馈应答信号，则发送方必须一直等待。每次只允许发送一帧，然后就陷入等待接收方确认信息的过程中，因此传输效率很低。

2）滑动窗口协议

从滑动窗口的概念看，停止-等待协议、后退N帧协议和选择重传协议只在发送窗口大小和接收窗口大小上有所差别：

停止-等待协议：发送窗口大小=1，接收窗口大小=1

后退N帧协议：发送窗口大小>1，接收窗口大小=1

选择重传协议：发送窗口大小>1，接收窗口大小>1

后退N帧协议

在后退N帧协议中，发送方不需要在收到上一个帧的ACK后才能开始发送下一帧，而是可以连续发送帧。当接收方检测出失序的信息帧后，要求发送方重发最后一个正确接收的信息帧之后的所有未被确认的帧；或者当发送方发送了N帧后，若发现该N个帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不又重传该出错帧及随后的N个帧，换句话说，接收方只允许按顺序接收帧。

选择重传协议

为了进一步提高信道的利用率，可设法只重传出现差错的数据帧或者是计时器超时的数据帧。但此时必须加大接收窗口，以便先收下发送序号不连续但仍处在接收窗口中的那些数据帧。等到所缺序号的数据帧收到后再一并送交主机。

16.TCP拥塞控制

拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。

1）慢开始与拥塞避免

慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。一次传输轮次之后拥塞窗口就加倍。这就是乘法增长，和后面的拥塞避免算法的加法增长比较。

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

当cwnd时，使用慢开始算法。

当cwnd>ssthresh时，改用拥塞避免算法。

当cwnd=ssthresh时，慢开始与拥塞避免算法任意。

拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。

17.IPv4

IP地址有网络号和主机号组成的。

A类（1~126）B类（128-191）C类（192-223）D类（224~239）E类（240~255）

其中A、B、C3类（如下表格）由InternetNIC在全球范围内统一分配，D、E类为特殊地址。

在各类IP地址中，有一些IP地址用于表示特殊用途，不用于做主机IP地址：

1）主机号全为0表示本网络本身。

2）主机号全为1表示本网络的广播地址。

3）127.0.0.0网络保留作为环路自检地址，此地址表示任意主机本身，目的地址为环路地址的IP数据报永远不会出现在任何网络上。

4）32位全为0，即0.0.0.0表示本网络上的本主机。

5）32位全为1，即255.255.255.255表示整个TCP/IP网络的广播地址。