【面试总结】计算机网络

Http协议与TCP/IP协议之间的关系

Http协议的长连接和短连接本质上式TCP协议的长连接和短连接。Http是应用层协议，建立在TCP协议之上。TCP是传输层协议，IP协议是网络层协议。TCP又依靠IP协议完成网络传输。

1. IP协议负责完成网络路由和网络寻址
2. TCP协议负责在IP协议的基础上，将所有数据包从发送端发送到接收端，并且保证接收的顺序和发送顺序一致。
3. TCP是可靠的，面向连接的协议。

如何理解Http是无状态的连接？

Http是无状态的协议，表示对事务的处理没有记忆能力。即上一次打开的网页和这次打开的网页没有任何连接，但是Http是无状态的不表示Http在一次连接中无法保证TCP的连接，也不能说明HTTP是采用UDP传输的。

cookie可以说是客户端保证Http状态的一种方案，session是服务端保证Http状态的一种方案。

Http的长连接和短连接

Http/1.0使用的是短连接服务，Http/1.1默认使用长连接。长连接指的是当访问一个网页完成时，不会断开TCP连接，当点击网页中其他资源，继续使用这个TCP链接进行传输。短连接即每次访问都重新建立TCP连接。若一个网页中有11张图片，js文件，那么就会建立11次连接，而长连接只需建立一次。

在Http响应头加入：(开启长连接 ) http/1.1默认开启

Collection:Keep-alive

关闭：

Collection:close

短连接低效体现在一下几点：

1. 每次建立TCP连接都需要三次握手和四次挥手，这样客户端和服务端需要耗费大量的资源来建立连接，占用CPU时间和资源。
2. 每次建立连接后，客户端和服务端都要分配发送和接收缓存数据 ，大大加大了存储数据的容量，占用CPU。
3. 当有大数据量的信息需要传输时，TCP的慢启动算法会限制服务端向客户端传输的速率。而采用Http/1.1则每次都会采用最大速率传输。

 

Http协议请求报文和响应报文

http 超文本传输协议 目前最流行的应用层协议之一。

请求报文：请求行，请求头，请求体组成。

HTTP请求报文格式:

请求行：请求方法 +(空格)URL +http协议版本。

请求头：客户端规定的一些参数。以key:value 形式传输。

请求体：需要传输的数据。

常见的请求头字段含义：

Accept： 浏览器可接受的MIME类型。

Accept-Charset：浏览器可接受的字符集。

Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。

Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。

Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。

Content-Length：表示请求消息正文的长度。

Host： 客户机通过这个头告诉服务器，想访问的主机名。Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。

If-Modified-Since：客户机通过这个头告诉服务器，资源的缓存时间。只有当所请求的内容在指定的时间后又经过修改才返回它，否则返回304“Not Modified”应答。

Referer：客户机通过这个头告诉服务器，它是从哪个资源来访问服务器的(防盗链)。包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。

User-Agent：User-Agent头域的内容包含发出请求的用户信息。浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。

Cookie：客户机通过这个头可以向服务器带数据，这是最重要的请求头信息之一。

Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。

From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。

请求方法：

GET：表示获取指定url的资源。最常用的获取资源的方式，一般将参数利用？携带在url之后，利用&分隔开，但是由于url有长度限制，以及隐秘信息也可能出现在url中，所以一般不使用get传输大数据和隐秘数据，安全性不高。幂等。

POST：表示想服务端提交数据，一般要setHeader: ContentType 设置请求头的文本格式，可以将信息放在请求体中用于传输。一般用于提交表单，上传图片等数据，安全性高于get.

HEAD:方式与GET用法相似，但是响应时没有响应体，一般用于确认URL资源有效性和资源日期等。

PUT：表示想指定URL上传资源，如果本来没有就上传，有就覆盖，但是本身没有安全性验证，一般使用POST上传。

DELETE:表示删除指定URL资源

TRACE:回显客户端请求的方法，用于追踪客户端请求信息。不常用。

OPTIONS方法比较少见，该方法用于请求服务器告知其支持哪些其他的功能和方法

响应报文：响应行+响应头+响应体。

响应行：协议版本   状态码  状态信息 

响应头：包含服务器的基本信息和相关描述。

响应体：返回的数据。

状态码

1XX：表示信息提示。即请求已经被服务端接收，但需要后续处理。（范围100~101）

2XX:表示请求成功处理，服务端接收到客户端发送的请求，并且成功处理。（200~206）

3XX：客户端重定向，表示客户端向服务端请求的资源被移到其他位置，服务端会返回状态码，并告诉新资源的地址，客户端接收到后重新对新的资源地址发起请求。（300~305）

4XX:客户端请求错误。表示服务端无法处理客户端发送来的请求，例如：请求格式错误，无法找到资源（400~415）

5XX：服务端错误。表示客户端正确发送请求，服务器内部错误导致无法处理请求。（500~505）

常用状态码：

200：请求成功。

302：重定向。

400：客户端请求语法错误，服务器无法理解。

403：服务器收到请求，但是拒绝提供服务。

404：请求资源不存在。

500：服务器内部错误。

503：服务器当前无法处理客户端请求，可能过一段时间可以恢复。

Cookie和Session的区别：

我们知道Http是无状态的协议，每次访问之后，服务器就不知道我们上次访问的身份，这就需要一种机制让服务器知道我们的身份。当我们第一次访问完服务器，会给浏览器返回一个Cookie文件缓存到本地，下一次访问的时候就会带上Cookie文件，服务器通过接受Cookie文件中的信息就能知道我们的身份。而Session则是一种存在于服务端保存用户信息的方法。

区别：

1. cookie存在于客户端，session存在于服务端
2. cookie中数据以key,value 形式存在。session则利用HashTable保存信息。
3. cookie对于客户端是可见，信息不安全，session存在于服务端，对于客户端不可见，信息相对安全
4. session的保存某种意义上借助于cookie,将sessionid写入cookie保存在客户端。下次访问带上cookie
5. 服务器的压力不同，由于session保存在服务器端，（默认过期时间为30分钟）所以当设置的有效期过长时候，大量的session会给服务器带来存储压力，此时建议使用cookie.
6. cookie文件较小，一般只存储不超过4KB的文件。
7. 支持的数据结构不同，一般cookie只能存放String类型数据，而session可以存放任意类型包括java对象。
8. 跨域名访问：cookie支持跨域名访问，而session不支持。

Cookie被禁用了，如何保存用户信息？

1. 使用url重写，将用户信息写入url的参数中（不安全，用户信息暴露在url中）
2. 利用隐藏域 hidden 携带用户信息

跨域访问问题

随着项目的复杂度越来越高，项目中的模块越来越多，会导致不同模块之间的cookie访问问题。例如：应用想要访问门户登陆的用户信息。 这样的场景，用户在门户登陆，然后跳转到应用下，那么如何获取--跨域访问的问题

解决：Cookie是由于用户访问页面而被创建用来保存用户信息的，而不是只有创建页面才能访问Cookie。一般来说属于创建Cookie页面的目录及其子目录下的模块都可以访问该Cookie，若想要父级目录或其他目录访问该Cookie，可以将Cookie设置目录层级。

 

Web缓存：

即浏览器缓存（代理服务器）保存最近访问的副本，浏览器请求时，会先相代理服务器发送Http请求，检查是否有数据副本，若没有则请求源服务器，发送http请求，然后获得响应并在本地浏览器缓存保存一个副本。

1. 客户端先跟web缓存器之间建立以个tcp连接，向其发送http请求
2. 若缓存器中有需要请求的副本，则直接向客户端返回这个副本
3. 若没有，想服务器转发该请求，请求源服务器。
4. 得到响应后，web缓存器在本地对响应进行副本拷贝，然后返回一个响应给服务端。

好处：不用频繁的向服务端发送请求，减少网络带宽和成本，以及直接返回更快的响应速度。

TCP和UDP的区别：

1. TCP是面向连接的，传输之前需要建立连接，UDP面向无连接，无需建立连接可以发送数据。
2. TCP传输数据保证可靠性，通过校验数据，数据顺序，超时重传，滑动窗口等。UDP尽最大可能发送，不保证数据顺序和可靠性。
3. TCP由于建立连接前三次握手，占用系统较多资源。UDP占用较少
4. 由于TCP的三次握手和确认机制，保证可靠性，TCP传输效率不高，慢。UDP可以保证较高的实时性，传输效率高
5. TCP传输数据量少，UDP可以传输较多的数据。

TCP的可靠性：

• 确认与重发：TCP发送一个数据后，接收端收到数据后给发送端发送一个确认信号表示接收到数据。发送端发送后，启动计时器，在一段时间内没有收到确认信号，会重新发送报文段。
• 数据校验：接收端会检验发送来的数据段首部和检验和。这是一个端到端的检验和，目的是为了检测数据在传输过程的变化，若收到的检验和有差错，会丢弃这个数据包。
• 数据分片发送与排序：应用数据被TCP分为最适合发送的数据块发送，与UDP不同，并且将接收到的失序的数据重新排序后交给应用层。
• 流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。利用滑动窗口机制，接收端会告诉发送端传输中可以接收的数据量的大小。
• 拥塞控制：当网络拥塞时，减少数据的发送。

TCP 的流量控制与拥塞控制可以说是一体的。流量控制是通过滑动窗口实现的，拥塞避免主要包含以下2个内容：

（1）慢开始，拥塞避免

（2）快重传，快恢复

流量控制：

发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。

为什么要设置窗口？

我们可以把窗口理解为缓冲区（但是有些窗口和缓冲区又不太一样）。

如果没有这些“窗口”，那么TCP没发送一段数据后都必须等到接收端确认后才能发送下一段数据，这样做的话TCP传输的效率实在是太低了。

解决的办法就是在发送端等待确认的时候继续发送数据，假设发送到第X个数据段是收到接收端的确认信息，如果X在可接受的范围内那么这样做也是可接受的。这就是窗口（缓冲区）引入的缘由。

1.1 窗口

（1）接收端窗口 rwnd     

接收端缓冲区大小。接收端将此窗口值放在 TCP 报文的首部中的窗口字段，传送给发送端。

（2） 拥塞窗口 cwnd (congestion window)    

发送端缓冲区大小

（3）发送窗口swnd

             发送窗口的上限值 = Min [rwnd, cwnd]

当 rwnd < cwnd 时，是接收端的接收能力限制发送窗口的最大值。

当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值。 

1.2 滑动窗口

发送端已发送了 400 字节的数据，但只收到对前 200 字节数据的确认，同时窗口大小不变。还可发送 300 字节。

发送端收到了对方对前 400 字节数据的确认，但对方通知发送端必须把窗口减小到 400 字节。现在发送端最多还可发送 400 字节的数据。

自己的话讲：

• 为什么要流量控制：TCP通过滑动窗口完成流量控制，在发送和接收的期间，接收端通过自己的资源状况，动态调节窗口的大小，实现流量的控制。
• 为什么设置窗口：窗口好比缓冲区，若没有窗口，那么TCP每发送一次数据就要等待接收端的确认信号，效率低下。
• 滑动窗口机制：当发送端利用初始窗口给接收端发送数据后，等待接收端的响应，接收端会将缓冲区大小（窗口大小）写在数据包中，并对已发送数据返回确认数据，发送端接收到确认数据后根据窗口大小移动窗口，动态改变窗口的大小。

 

拥塞控制：

目的： 拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载

对比流量控制：拥塞控制是一个全局的过程，涉及到所有的主机、路由器、以及降低网络相关的所有因素。流量控制往往指点对点通信量的控制。是端对端的问题。

慢启动：

发送端维护一个拥塞窗口，发送端会根据拥塞窗口的大小来发送窗口大小的数据。拥塞窗口不是固定不变的，初始为1，当接收到接收端报文后，翻倍增长，使得发送窗口也增大。即由小到大动态变化窗口。

   当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以一次传输轮次之后拥塞窗口就加倍。这就是乘法增长，和后面的拥塞避免算法的加法增长比较。

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

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

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

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

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

慢开始算法---门限值（防止窗口过大导致拥塞）---改用拥塞避免算法 

一旦发生拥塞，将拥塞窗口重新设为1，并将门限值设为发生拥塞时窗口的1/2，执行慢开始算法。

TCP对应的协议和UDP对应的协议：

Tcp对应的协议：

• http：超文本传输协议
• ftp:文件传输协议，端口21
• smtp:简单邮件传输协议，用于发送邮件，25
• pop3:邮局传输协议第三代，用于接收邮件，与smtp对应。110
• Telnet:一种用于远程登录的端口。端口23，用于可用自己身份登录远程计算机，可以提供基于DOS下的通信服务。

UDP对应的协议：

• DNS：域名解析服务，端口53，将域名解析为Ip地址。
• SNMP：简单网络管理协议，端口161，用于管理网络设备，由于网络设备很多，无连接体现其优点
• TFTP：简单文件传输协议。

域名服务器：

根域名服务器：管理所在域所有的顶级服务器，拥有所有顶级服务器的域名和Ip地址。

顶级域名服务器：拥有该域下所有二级域名服务器地址和Ip

本地域名服务器：属于本地域的域名服务器。当客户发送域名解析请求，就是给本地域名服务器

 

域名解析的过程：

1. 浏览器会检查缓存中是否有该域名的地址，有返回
2. 操作系统检查本地缓存中是否有域名地址，若没有下一步
3. 请求本地域名服务器，本地域名服务器查询自己的缓存，有就返回，没有的话向根域名服务器发起解析请求
4. 根域名服务器根据请求的，给本地域名服务器返回一个所在域的顶级服务器地址
5. 本地服务器想顶级服务器发起请求，顶级服务器接收请求并查询，将结果返回
6. 本地域名服务器缓存该结果，并返回给用户
7. 本地用户将域名缓存到本地系统。

报文格式

TCP报文段：

源端口：表示发送端的端口号

目标端口：接收端的端口号

序号（seq）:表示发送数据的第一个字节代表的序号，TCP发送数据每个字节代表一个序号，若起始序号为100，发送300字节，那么下一个报文段序号为400。

确认序号：ack,表示下一个期待收到的序列号，表示该序号之前的数据序列已经正确收到。确认号只有ACK标志号置1时才有作用。

数据偏移：表示整个TCP报文的数据量偏移。

保留字：保留使用一般为0

标志字段：

• URG：紧急指针标志，置1时，紧急指针标志有效
• ACK：确认标志序号，置1时，确认号有效
• SYN：请求连接标志，置1时，表示为一个请求连接请求。在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。
• FIN：释放连接表示，置1时，表示无数据发送，请求释放连接。
• RST：重置连接标志。用于重置由于主机崩溃或者其他错误出现的连接。或者用于拒绝非法报文的连接
• PSH：push数据表示，当置1时，表示该数据为push标志，应立刻将该报文段发送给应用程序，而不是在缓冲区排队。

窗口：表示滑动窗口的大小，由接收端告诉发送端缓冲区的大小，用来控制发送端的发送速率，达到流量控制的效果。16bit

检验和：奇偶校验，校验整个报文段包括头部和数据部。16bit,由发送端计算和发送，接收端校验。

紧急指针：URG置1时有效，紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。

选项和填充：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。

数据字段：可选项，可以不填。TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

UDP报文：

首部字段很简单，只有8个字节，由4个字段组成，每个字段的长度都是两个字节。

• 源端口号：发送端端口号
• 目的端口号：目的端口号
• 数据包长度：整个udp数据包的长度
• 检验和：校验和

TCP连接的三次握手和四次挥手：

 

• 第一次握手:首先由客户端主动创建TCB，然后发送请求连接报文，同步标志SYN=1，发送序列号位x,请求主动连接，同时自身进入同步发送状态SYN-SENT。
• 第二次握手：服务端接收到客户端发来的连接请求后，被动打开创建TCB，同意连接的情况下，发送确认报文SYN=1,ACK=1。发送确认序列ack=x+1,seq=y.同时自身进入SYN-RCVD同步接收状态，等待客户端的确认进行连接。
• 第三次：客户端接收到服务的连接确认信号，开启连接，并将ACK=1，seq=x+1,ack=y+1发送给服务端，自身进入启动状态。
• 服务端接收到客户端的连接确认信号，进入启动状态，可以发送数据。

为什么要三次握手，不能两次？

• 采用三次握手是为了防止，已失效的报文段再次向服务端发起连接。若之前客户端发送的报文段因网络延迟消失一段时间，客户端又重新发送一个报文段用于连接，此时已经建立连接，若失效的报文段此时到达服务端，服务端给客户端发送确认后，没有等待客户端的回应就进入启动状态，这样浪费了资源。而三次握手的情况下，客户端对于已发送的报文不会给服务端发送确认，那么服务端不会进入连接状态。

Server端易受到SYN攻击？

• 服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。
• 防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。

TCP四次挥手：

• 首先服务端和客服端都处于启动状态，客户端主动提出释放连接，并向服务端发送连接释放报文及最后的信息序列，FIN=1，seq = x。然后进入FIN-WAIT-1状态，等待服务端的确认。
• 然后服务端接收到客户端的连接释放请求后，通知相关进程，但此时服务端并不一样立刻释放连接，还有数据要传给客户端，会先发送一个确认信号给客户端ACK=1，seq= y,ack= x+1。并进去CLOSE-wait状态，将剩下的数据继续发送给客户端。
• 客户端接收道服务端发送的确认信号后，进入FIN-WAIT-2状态，并等待服务端发送最后的数据。
• 当服务端发送完数据后，假设此时的序列为w,会向客户端发送连接释放报文，表示自己已经发送完数据可以释放连接了。FIN=1，ACK=1，seq = w,ack = x+1。服务端进入LAST-ACK状态，最后确认状态。
• 客户端接收到服务端发来的连接释放报文，确认连接释放后，向服务端回发一个确认报文ACK=1，seq=x+1,ack=w+1。并进去TIME-WAIT状态，等待2个MSL（最大报文寿命）后关闭。
• 服务端接收到客户端发来的确认信息后，进入CLOSE状态。

为什么要等待2个MSL Maximum Segment Lifetime后客服端关闭？

• 第一个原因：防止确认报文丢失，服务端未收到确认释放报文，在2个MSL周期之间，保证服务端没有收到确认报文后，重传连接释放报文，保证服务端正常关闭。
• 第二个原因：使得在该连接时间内的所有报文段都失效。再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段

为什么连接是三次握手，释放连接是四次握手？

• 因为申请连接的时候客服端和服务端都处于关闭状态，服务端接收到连接请求后，可以在一个报文段中发送回SYN和ACK信号，同时表示同意连接申请和确认。但是释放连接的时候，服务端可能还有报文段需要发送给客户端，就需要分开将FIN信号发送给客户端。（因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。）

OSI模型及其相应的协议：

OSI七层网络模型	TCP/IP四层概念模型	功能	对应网络协议
应用层（Application）	应用层	文件传输，电子邮件，文件服务，虚拟终端	HTTP、TFTP, FTP, NFS, WAIS、SMTP
表示层（Presentation）		数据格式化，代码转换，数据加密	Telnet, Rlogin, SNMP, Gopher
会话层（Session）		解除或建立与别的接点的联系	SMTP, DNS
传输层（Transport）	传输层	提供端对端的接口	TCP, UDP
网络层（Network）	网络层	为数据包选择路由	IP, ICMP, ARP, RARP, AKP, UUCP
数据链路层（Data Link）	数据链路层	传输有地址的帧以及错误检测功能	FDDI, Ethernet, Arpanet, PDN, SLIP, PPP
物理层（Physical）		以二进制数据形式在物理媒体上传输数据	IEEE 802.1A, IEEE 802.2到IEEE 802.11

 

IP协议报文格式：

IP报文是在网络层传输的数据单元，也叫IP数据报。

• 版本：IP协议的版本，目前的IP协议版本号为4，下一代IP协议版本号为6。
• 首部长度：IP报头的长度。固定部分的长度（20字节）和可变部分的长度之和。共占4位。最大为1111，即10进制的15，代表IP报头的最大长度可以为15个32bits（4字节），也就是最长可为15*4=60字节，除去固定部分的长度20字节，可变部分的长度最大为40字节。
• 服务类型：Type Of Service。
• 总长度：IP报文的总长度。报头的长度和数据部分的长度之和。
• 标识：唯一的标识主机发送的每一分数据报。通常每发送一个报文，它的值加一。当IP报文长度超过传输网络的MTU（最大传输单元）时必须分片，这个标识字段的值被复制到所有数据分片的标识字段中，使得这些分片在达到最终目的地时可以依照标识字段的内容重新组成原先的数据。
• 标志：共3位。R、DF、MF三位。目前只有后两位有效，DF位：为1表示不分片，为0表示分片。MF：为1表示“更多的片”，为0表示这是最后一片。
• 片位移：本分片在原先数据报文中相对首位的偏移位。（需要再乘以8）
• 生存时间：IP报文所允许通过的路由器的最大数量。每经过一个路由器，TTL减1，当为0时，路由器将该数据报丢弃。TTL 字段是由发送端初始设置一个 8 bit字段.推荐的初始值由分配数字 RFC 指定，当前值为 64。发送 ICMP 回显应答时经常把 TTL 设为最大值 255。
• 协议：指出IP报文携带的数据使用的是那种协议，以便目的主机的IP层能知道要将数据报上交到哪个进程（不同的协议有专门不同的进程处理）。和端口号类似，此处采用协议号，TCP的协议号为6，UDP的协议号为17。ICMP的协议号为1，IGMP的协议号为2.
• 首部校验和：计算IP头部的校验和，检查IP报头的完整性。
• 源IP地址：标识IP数据报的源端设备。
• 目的IP地址：标识IP数据报的目的地址。

IP地址的划分：

IP地址是一个32位的标识符，我们将IP地址划分为若干个固定类，每一类地址都是由两个固定长度的字段组成，其中第一个字段是网络号，标志主机连接到的网络，第二个是主机号，一个IP地址在整个Internet上是唯一的。

常用的地址是A,B,C三类地址，通过它们的位数设置，我们可以得出这几类地址表示的范围：

其中还有一些特殊的IP地址，在特定情况下使用：

Https和Http之间的区别：

1. http是明文传输，信息没有加密操作。https是加密传输，安全性高于http
2. 采用不同的传输方式，对应的端口不同http一般使用80端口，而https使用443
3. http传输不需要CA证书，而https传输时需要CA证书，安全级别越高的证书价格越高，很少有免费证书。
4. https协议为http+ssl协议构成的协议。

SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security，TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

CA证书中包含什么信息

• 证书信息：过期时间和序列号
• 所有者信息：姓名等
• 所有者公钥

Https的实现原理：

• 首先客户端向服务端发送一个https请求
• 服务端必须拥有CA安全证书，服务端接收到客户端的请求后，将安全证书（包含公钥）发回给客户端。
• 客户端接收到证书，验证证书的有效性。证书有效后，生成一个随机数（作为私钥），将私钥用公钥加密然后发送给服务端。
• 服务端接收到密文后，利用公钥解密密文获取私钥，此时两端可以利用对称秘钥进行加密信息传输。

Https的缺点：

• https由于加密操作，握手时间比http时间长。耗时比http长50%,系统开销大于http。

• https缓存效率不如http。

• SSL证书需要成本，安全等级越高的证书，成本越高。