计算机网络体系结构
体系介绍
计算机网络体系结构分为3种：OSI体系结构、TCP / IP体系结构、五层体系结构
- 低三层为通信子网，负责数据传输；
- 高三层为资源子网，相当于计算机系统，完成数据处理；
- 传输层承上启下；
TCP/IP体系结构详介
OSI体系结构详介
TCP 协议
定义
Transmission Control Protocol，即 传输控制协议，属于传输层通信协议，基于TCP的应用层协议有HTTP、SMTP、FTP、Telnet 和 POP3。
特点
面向连接：使用TCP传输数据前，必须先建立TCP连接；传输完成后再释放连接。
全双工通信：建立TCP连接后，通信双方都能发送数据。
可靠：通过TCP连接传送数据：不丢失、无差错、不重复、按序到达。
面向字节流：数据以流的形式进行传输。
报文段格式
报文段 = 首部 + 数据 2部分
下面分别对其中的字段进行介绍：
建立连接-三次握手
过程说明：
客户端向服务器发出连接请求报文，这时报文首部中的同部位
SYN=1，同时选择一个初始序列号Seq=X，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该
ACK=1，SYN=1，确认号是Ack=X+1，同时也要为自己初始化一个序列号Seq=Y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。TCP客户进程收到确认后，还要向服务器给出确认。确认报文的
ACK=1，Ack=Y+1，自己的序列号Seq=X+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。
为什么TCP建立连接需三次握手
释放连接-四次挥手
过程说明：
客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，
FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。服务器收到连接释放报文，发出确认报文，
ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后，此时，客户端就进入
FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，
FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。客户端收到服务器的连接释放报文后，必须发出确认，
ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。服务器只要收到了客户端发出的确认，立即进入
CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么TCP释放连接需要四次挥手
为了保证客户端发送的最后1个连接释放确认报文能到达服务器，从而使得服务器能正常释放连接。
关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了，但未必你所有的数据都发送给对方了，所以你不必马上关闭SOCKET，也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。防止上文提到的早已失效的连接请求报文出现在本连接中。
客户端发送了最后1个连接释放请求确认报文后，再经过2MSL时间，则可使本连接持续时间内所产生的所有报文段都从网络中消失。即在下1个新的连接中就不会出现早已失效的连接请求报文。
释放连接时为什么TIME-WAIT状态必须等待2MSL时间
首先说下什么是MSL:MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，重置时间等待计时器（2MSL）。
如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
第二，A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。
客户端突然挂掉了怎么办
正常连接时，客户端突然挂掉了，如果没有措施处理这种情况，那么就会出现客户端和服务器端出现长时期的空闲。
解决办法是在服务器端设置保活计时器，每当服务器收到客户端的消息，就将计时器复位。超时时间通常设置为2小时。若服务器超过2小时没收到客户的信息，他就发送探测报文段。若发送了10个探测报文段，每一个相隔75秒，还没有响应就认为客户端出了故障，因而终止该连接。
滑动窗口协议
基础概念
发送窗口：任意时刻，发送方维持的一组连续的、允许发送帧的帧序号；用于对发送方进行流量控制；
接收窗口：任意时刻，接收方维持的一组连续的、允许接收帧的帧序号；用于控制可接收哪些数据帧、不可接收哪些数据帧，接收方只有当收到数据帧的序号落入接收窗口内才允许将该数据帧收下，否则一律丢弃。
工作原理
发送端
- 每收到一个确认帧，发送窗口就向前滑动一个帧的距离。
- 当发送窗口内无可发送的帧时（即窗口内的帧全部是已发送但未收到确认的帧），发送方就会停止发送，直到收到接收方发送的确认帧使窗口移动，窗口内有可以发送的帧，之后才开始继续发送。
接收端
- 当收到数据帧后，将窗口向前移动一个位置，并发回确认帧，若收到的数据帧落在接收窗口之外，则一律丢弃。
重要特性
只有接收窗口向前滑动、接收方发送了确认帧时，发送窗口才有可能（只有发送方收到确认帧才是一定）向前滑动。
停止-等待协议、后退N帧协议 & 选择重传协议只是在发送窗口大小和接收窗口大小上有所差别：
- 停止等待协议：发送窗口大小=1，接收窗口大小=1；即 单帧滑动窗口 等于 停止-等待协议
- 后退N帧协议：发送窗口大小>1，接收窗口大小=1。
- 选择重传协议：发送窗口大小>1，接收窗口大小>1。
当接收窗口的大小为1时，可保证帧有序接收。
数据链路层的滑动窗口协议中，窗口的大小在传输过程中是固定的（注意要与TCP的滑动窗口协议区别）。
自动重传请求协议ARQ
定义
Auto Repeat reQuest，传输出现差错时，接收方自动请求发送方重传出错的数据。
作用
保证信道的数据传输无差错。
机制
- 确认机制
发送方每发送一帧，要等到接收方的应答信号后才能发送下一帧；
接收方每接收一帧，都要反馈一个应答信号，表示可接收下一帧；
若接收方不反馈应答信号，则发送方必须一直等待。 - 超时重传机制
发送方在发送某个数据帧后就开启计时器；
在一定时间内若没得到发送的数据帧的确认帧，则重新发送该数据帧，直到发送成功为止。
类型
- 停等式ARQ（Stop-and-Wait）
- 后退N帧ARQ（Go-Back-N）
- 选择重传ARQ（Selective Repeat）
停等式ARQ（Stop-and-Wait）
原理：
具体描述：
- 发送方每发送一帧，要等到接收方的应答信号后才能发送下一帧；
- 接收方每接收一帧，都要反馈一个应答信号，表示可接下一帧；
- 若接收方不反馈应答信号，则发送方必须一直等待。
后退N帧协议
原理：
具体描述：
- 发送方：采用多帧滑动窗口的原理，可连续发送多个数据帧 而不需等待对方确认
- 接收方：采用
累计确认&后退N帧的原理，只允许按顺序接收帧。
累计确认
收到多个数据分组后，只需对按序到达的最后1个分组发送确认而不必对收到的每个分组逐个发送确认即可表示到该分组为止的所有分组都已正确收到。
优点：实现简单；数据丢失不必重传。
缺点：不能向发送方反映出接收方已正确收到所有分组信息。
后退N帧
退回来重传已发送过的N个分组。保证按序接收数据帧。
后退N帧协议的接口窗口长度 = 1，若采用n个比特对帧编号，则其发送窗口WT应满足1≤WT≤2n-1;若发送窗口尺寸大于2n-1，则会造成接收方无法分辨新帧和旧帧。
选择重传ARQ（Selective Repeat）
原理：
优缺点：
TCP超时重传
在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。
影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO，Retransmission TimeOut）。RTO的值被设置过大过小都会对协议造成不利影响。
（1）RTO设长了，重发就慢，没有效率，性能差。
（2）RTO设短了，重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
连接往返时间（RTT，Round Trip Time），指发送端从发送TCP包开始到接收它的立即响应所消耗的时间。
RTO理论上最好是网络 RTT 时间，但又受制于网络距离与瞬态时延变化，所以实际上使用自适应的动态算法（例如 Jacobson 算法和 Karn 算法等）来确定超时时间。
TCP流量控制
TCP流量控制主要是针对接收端的处理速度不如发送端发送速度快的问题，消除发送方使接收方缓存溢出的可能性。
TCP流量控制主要使用滑动窗口协议，滑动窗口是接受数据端使用的窗口大小，用来告诉发送端接收端的缓存大小，以此可以控制发送端发送数据的大小，从而达到流量控制的目的。
接收端通过TCP首部的窗口大小字段反馈当前可接收的字节数。
对于发送端的数据缓冲区有这些量：
LastByteSent是目前发送的最后1字节的数据编号；LastByteAckd是目前接收到确认的最后1字节的数据编号；LastByteRcvd：接收端从网络接收的最后一个字节序号；LastByteRead：上层应用程序接收的最后一个字节序号；Rcvwin是窗口大小。
鉴于每次发送方都是收到ACK之后滑动窗口继续发送，发送到LastByteSent这个位置，LastByteSent-LastByteAckd也就是这次发送数据的多少，那么只要满足：LastByteSent–LastByteAckd<=RcvWin(接收端空闲窗口大小) 就会保证不会溢出了。
那么接收端
RcvWin怎么算呢？
假设接收端缓冲区大小为RcvBuffer,那么LastByteRcvd–LastByteRead就是已经接受但是还没有传递给上层的数据。所以空闲区域RcvWin= RcvBuffer-(LastByteRcvd–LastByteRead)。
TCP拥塞控制
TCP发送方可能因为IP网络的拥塞而被遏制，TCP拥塞控制就是为了解决这个问题（注意和TCP流量控制的区别）。
TCP拥塞控制的几种方法：慢启动，拥塞避免，快重传和快恢复。在了解这几种方法之前，先了解下拥塞窗口、慢开始算法、拥塞避免算法。
拥塞窗口
定义
发送方维持一个叫做拥塞窗口 cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态变化。发送方的让自己的发送窗口=min(cwnd，接受端接收窗口大小）。
发送方控制拥塞窗口的原则
只要网络没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始算法
当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是 先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。
通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。
每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下：
- 当
cwnd < ssthresh时，使用上述的慢开始算法。 - 当
cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法。 - 当
cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞控制避免算法。
拥塞避免算法
让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
拥塞避免并不可避免拥塞，只是将拥塞窗口按现行规律缓慢增长，使得网络比较不容易出现拥塞。
慢开始和拥塞避免算法的实现举例
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。
如下图，用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。
过程说明：
快重传
原理
接收方：每收到一个失序的报文段后 就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时才进行捎带确认。
发送方：只要一连收到3个重复确认就立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器到期。
作用
由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。
示例
快恢复
与快重传配合使用的还有快恢复算法，其主要有以下两个要点：
- 当发送方连续收到接收方发来的三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半（这个减半指的是变成发生阻塞时的阻塞窗口大小的一半），这是为了预防网络发生拥塞。（注意：接下来不执行慢开始算法）
- 由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd(拥塞窗口)值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，使拥塞窗口缓慢的线性增大。
注：由于跳过了拥塞窗口（cwnd）从1起始的慢开始过程，所以称为：快恢复。
此处网络不会发生网络拥塞，因若拥塞，则不会收到多个重复确认报文。
示例如下图：
TCP四种计时器
TCP中有四种计时器（Timer），分别为：
- 重传计时器：Retransmission Timer
- 坚持计时器：Persistent Timer
- 保活计时器：Keeplive Timer
- 时间等待计时器：Timer_Wait Timer
重传计时器
TCP是可以保证数据可靠传输的。怎么保证呢？带确认的重传机制。
在滑动窗口协议中，接收窗口会在连续收到的包序列中的最后一个包向接收端发送一个ACK，当网络拥堵的时候，发送端的数据包和接收端的ACK包都有可能丢失。
TCP为了保证数据可靠传输，就规定在重传的“时间片”到了以后，如果还没有收到对方的ACK，就重发此包，以避免陷入无限等待中。
当TCP发送报文段时，就创建该特定报文的重传计时器。可能发生两种情况：
1）若在计时器截止时间到之前收到了对此特定报文段的确认，则撤销此计时器。
2）若在收到了对此特定报文段的确认之前计时器截止时间到，则重传此报文段，并将计时器复位。
坚持计时器
专门对付零窗口通知而设立的。
先来考虑一下情景：
发送端向接收端发送数据包知道接收窗口填满了，然后接收窗口告诉发送方接收窗口填满了停止发送数据。此时的状态称为“零窗口”状态，发送端和接收端窗口大小均为0.直到接受TCP发送确认并宣布一个非零的窗口大小。但这个确认会丢失。
我们知道TCP中，对确认是不需要发送确认的。若确认丢失了，接受TCP并不知道，而是会认为他已经完成了任务，并等待着发送TCP接着会发送更多的报文段。
但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口大小。双方的TCP都在永远的等待着对方。
要打开这种死锁，TCP为每一个链接使用一个持久计时器。当发送TCP收到窗口大小为0的确认时，就坚持启动计时器。当坚持计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文。
这个报文段只有一个字节的数据。他有一个序号，但他的序号永远不需要确认；甚至在计算机对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接受TCP：确认已丢失，必须重传。
坚持计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。
发送端继续发送探测报文段，将坚持计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每隔60秒就发送一个探测报文，直到窗口重新打开。
保活计时器
保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时间的空闲。
假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远的处于打开状态。
要解决这种问题，在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。通常设置为两小时。
若服务器过了两小时还没有收到客户的信息，他就发送探测报文段。若发送了10个探测报文段（每一个间隔75秒）还没有响应，就假定客户端出了故障，因而就终止了该连接。
这种连接的断开当然不会使用四次握手，而是直接硬性的中断和客户端的TCP连接。
时间等待计时器
时间等待计时器是在四次挥手手的时候使用的。即在释放连接的最终阶段，客户端还要等待
2MSL（MSL=maxinum segment lifetime最长报文生存时间，2MSL就是两倍的MSL）才能真正的关闭连接。
UDP协议
定义
User Datagram Protocol，即 用户数据报协议，属于 传输层通信协议。基于UDP的应用层协议有 TFTP、SNMP 与 DNS。
特点
无连接：使用UDP传输数据前，不需要建立UDP连接，就像写信，写好信交给邮局，其余不需要管。
不可靠：UDP的数据包发送后，不管其是否会到达接收方，故可能出现丢包现象。
面向报文：数据以数据报文(包)的形式传输，UDP数据报文长度无限制，都一次性发送，不像TCP会拆分。
无拥塞控制：由于是不可靠传输，即不管是否到达接收方，故不需拥塞控制。
报文段格式
伪首部：计算检验和（不向下传送，也不向上递交）。
源端口：需要对方回信时使用，如果不需要则设为全0。
目的端口：终点交付报文时用到。
长度：UDP用户数据报的长度，最小值是8（仅有首部）。
检验和：检测UDP用户数据报在传输中是否有错，若有错则丢弃。
TCP、UDP的区别
HTTP协议
定义
HyperText Transfer Protocol，超文本传输协议，规定了应用进程之间的通信准则，属于应用层协议。
特点
- 无连接，即交换
HTTP报文前，不需要建立HTTP连接。 - 无状态，即数据传输过程中不保存任何历史状态信息，该特性简化了服务器的设计，使服务器更容易支持大量并发的
HTTP请求。 - 传输格式简单，即请求时只需传送请求方法和路径。
- 传输可靠性高，采用
TCP作为运输层协议。 - 兼容性好，支持
B/S、C/S模式。 - 灵活性高，
HTTP允许传输任意类型的数据对象。
工作方式
HTTP协议采用请求/响应的工作方式，具体工作流程如下：
HTTP报文
HTTP报文分为：请求报文、响应报文。
请求报文
HTTP的请求报文由请求行、请求头、请求体组成。如下图：
请求行
请求行 = 请求方法 + 请求路径 + 协议版本
用于声明 请求方法 、主机域名、资源路径 、协议版本。
各部分组成介绍如下图：
请求头
主要用于声明客户端、服务器/报文的部分信息。采用header(字段名):value(值)的方式。
请求和响应报文的通用
Header
| 名称 | 作用 |
|---|---|
| Content-Type | 请求体/响应体的类型，如：text/plain、application/json |
| Accept | 说明接收的类型，可以多个值，用，（半角逗号）分开 |
| Content-Length | 请求体/响应体的长度，单位字节 |
| Content-Encoding | 请求体/响应体的编码格式，如gzip,deflate |
| Accept-Encoding | 告知对方我方接受的Content-Encoding |
| ETag | 给当前资源的标识，和Last-Modified、If-None-Match、If-Modified-Since 配合，用于缓存控制 |
| Cache-Control | 取值为一般为no-cache或max-age=Xx，XX为个整数，表示该资源缓存有效期（秒) |
常见的请求
Header
| 名称 | 作用 |
|---|---|
| Authorization | 用于设置身份认证信息 |
| User-Agent | 用户标识，如：OS和浏览器的类型和版本 |
| If-Modified-Since | 值为上一次服务器返回的Last-Modified值，用于确认某个资源是否被更改过，没有更改过（304）就从缓存中读取 |
| If-None-Match | 值为上一次服务器返回的ETag值，一般会和If-Modified-Since一起出现 |
| Cookie | 已有的Cookie |
| Referer | 表示请求引用自哪个地址，比如你从页面A跳转到页面B时，值为页面A的地址 |
| Host | 请求的主机和端口号 |
请求体
主要用于存放需发送给服务器的数据信息。
使用方式共3种，如下图：
响应报文
HTTP响应报文包括：状态行、响应头、响应体。结构如下图：
状态行
状态行 = 协议版本 + 状态码 + 状态信息组成
主要用于声明协议版本、状态码、状态码描述。
各部分组成具体介绍如下：
响应头
主要用于声明客户端、服务器/报文的部分信息。采用header(字段名):value(值)的方式。
常见响应
Header
| 名称 | 作用 |
|---|---|
| Date | 服务器的日期 |
| Last-Modified | 该资源最后被修改时间 |
| Transfer-Encoding | 取值为一般为chunked，出现在Content-Length不能确定的情况下，表示服务器不知道响应版体的数据大小，一般同时还会出现Content-Encoding 响应头 |
| Set-Cookie | 设置Cookie |
| Location | 重定向到另一个URL，如输入浏览器就输入baidu.com回车，会自动跳到https://www.baidu.com，就是通过这个响应头控制的 |
| Server | 后台服务器 |
响应体
主要用于存放需返回给客户端的数据信息。使用方式同请求报文的请求体。
HTTP1.1 与 HTTP1.0的区别
Http1.1 比 Http1.0 多了以下优点：
- 引入持久连接，即 在同一个
TCP的连接中可传送多个HTTP请求 & 响应； - 多个请求 & 响应可同时进行、可重叠；
- 引入更加多的请求头 & 响应头；
其他知识
浏览器中输入URL到页面返回的全过程
总共分为7个步骤，流程如下图：
第一步：域名解析
- 浏览器查找浏览器缓存，如果有域名对应的IP地址则返回，如果没有继续查找。
- 浏览器查看本机的host文件，如果有域名对应的IP地址则返回，如果没有继续查找。
- 然后是路由器缓存，路由器一般有自己的缓存，如果有域名对应的IP地址则返回，如果没有继续查找。
- 接着是对本地DNS服务器进行递归查询，看是否有域名对应的IP。主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）
- 本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地服务器自己进行后续的查询。（而不是替代本地服务器进行后续查询）。
- 根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址。
- 本地域名服务器向顶级域名服务器dns.com进行查询。
- 顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.baidu.com的IP地址。
- 本地域名服务器向权限域名服务器dns.baidu.com进行查询。
- 权限域名服务器dns.baidu.com告诉本地域名服务器，所查询的主机www.baidu.com的IP地址。
本地域名服务器最后把查询结果告诉主机。
第二步：建立TCP连接，三次握手
第三步：Web浏览器向Web服务端发送HTTP请求报文
第四步：服务器响应HTTP请求
第五步：浏览器解析HTML代码，并请求HTML代码中的资源（JS，CSS，图片）（这是自动向服务器请求下载的）
第六步：浏览器对页面进行渲染呈现给客户
第七步：断开TCP连接，四次挥手
IP地址(IPV4)
定义
连接在Internet中的每一台主机（或 路由器）的全球唯一的标识符。
组成
IP地址 = 32位 = 网络号 + 主机号；即IP地址::={<网络号>，<主机号>}
网络号：标志主机（或路由器）所连接到的网络。一个网络号在整个因特网范围内必须是唯一的。
主机号：标志该主机（或路由器）。一个主机号在它面前的网络号所指明的网络范围必须是唯一的。
不同类型的IP地址，其主机号 & 网络号所占字节数不同；故：一个IP地址在整个网络范围内是唯一的。
分类
传统的IP地址是分类的地址，分为A，B，C，D，E五类，区别在于网络号 & 主机号占的字节数不同。
特别注意：在各类IP地址中，有一些IP地址用于特殊用途，不能用于做主机IP地址
Cookie与Session
