IP协议可以将不同的网络接口进行互连,并向其上的TCP协议和UDP协议提供网络互连服务。而TCP协议在享受IP协议提供网络互连服务的基础上，可向引用层的相应协议提供可靠传输服务，UDP在享受IP协议提供网络互连服务的基础上,可向应用层的协议提供不可靠的传输服务; IP协议作为TCP/IP体系结构中的核心协议，一方面负责互连不同的网络接口，另一方面，为各种网络应用提供服务。 TCP/IP协议体系中包含了大量的协议，IP协议和TCP协议是其中非常重要的两个协议，因此用TCP和IP来表示整个协议大家族。

前面学习的物理层，数据链路层，以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。

下面这个五层结构的图能记住就尽量记住：

网络层的作用范围是主机到主机，而在计算机网络中进行通信的真正实体是通信【两端主机中的进程】。接下来我们学习的运输层，它的作用范围是应用进程到应用进程。（也称为端到端）

每个应用进程都有一个端口来标识它们，端口是用来区分不同应用进程的标识符。

2.端口号，复用与分用

端口号（重点）

运输层【直接】为【应用进程】间的逻辑通信提供服务。运输层使用端口号来区分不同的应用程序。

为什么不能使用进程标识符PID来区分各进程？

因为因特网上的计算机并不是使用统一的操作系统，不同的操作系统使用不同格式的进程标识符。

TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。

端口号使用16比特表示，取值范围0~65535。
- 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议
- 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。如Microsoft RDP微软远程桌面使用的端口是3389
- 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用

端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同的端口号是没有联系的

复用与分用

发送方的某些应用进程所发送的不同应用报文，在运输层使用UDP协议进行封装，这是UDP复用；若用TCP封装则称TCP复用。
运输层使用端口号区分不同进程，不管使用何种协议封装的报文，在网络层都需要使用IP协议封装成IP数据报，这是IP复用，数据报中协议字段的值用来表名封装的是何种协议数据单元
根据协议字段的值，将IP数据报封装的协议数据单元上交运输层的过程叫IP分用
同理，UDP根据端口号将数据交给应用进程叫做UDP分用；TCP根据端口号将数据交给应用进程叫做TCP分用

不管在运输层使用的是UDP还是TCP协议，在网络层都会被封装成IP协议。

3.TCP和UDP大对比（重点）

TCP和UDP是TCP/IP协议中最为重要的两个协议。

UDP：用户数据协议（User Datagram Protocol）

TCP：传输控制协议（Transmisson Controller Protocol）

UDP和TCP的对比总结：（下面会详细讲解，这里先放总结）

UDP	TCP
无连接	面向连接
支持一对一，一对多，多对一和多对多交换通信。	每一条TCP连接只能有两个端点EP,只能是一对一通信
对应用层交付的报文直接进行打包	面向字节流
尽最大努力交付，也就是不可靠（传输过程出现无码和数据报的丢失都不会管，仅仅丢弃，什么也不会做）	提供可靠的传输,使用流量控制和拥塞控制
报文的首部开销小，仅仅8个字节	首部最小20字节,最大60字节

①数据传输过程是否进行连接：

②传输状态：

③对数据的处理：

UDP对应用进程交下来的报文，既不进行合并，也不进行拆分，而是保留这些报文的边界。换句话说，UDP是面向应用报文的。

TCP把应用进程交付下来的数据块仅仅是看作一串无结构的字节流。 TCP并不知道这些待传送的字节流的含义，仅将它们进行编号，并存储在自己的发送缓存中。TCP根据自己的发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送。接收方的TCP，一方面从所接收到的TCP报文段中取出数据载荷部分并存储在接收缓存中，一方面将接收缓存中的一些自己交付给应用进程。 TCP不保证接收方应用进程所收到的数据块与发送方应用进程所发出的数据块具有对应大小的关系。

注意：在实际网络中基于TCP连接两端可以同时进行TCP报文的段的发送和接收，也就是全双工通信。在实际应用过程中，一个TCP报文段包含上千个字节都是很常见的。

④是否保证数据可靠：

⑤TCP与UDP的报文段首部对比：

4.TCP的流量控制

一般来说，我们希望数据传输能快一些，但如果发送方把数据发送得过快，接收方就可能来不及接收，这会造成数据的丢失，流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

所谓的流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用【滑动窗口】就可以很好的实现流量控制；

发送数据的主机：有发送窗口，表示主机可以发送的字节数量。

接受数据的主机：有接受窗口，表示主机可以接受的字节数量。

seq: 这里的seq是 TCP报文段首部中的序号字段。取值为1表示TCP报文段数据载荷的第1个字节的序号是1。

注意：下面的案例并没有考虑拥塞窗口，在实际的生产中，TCP发送方的发送窗口 = min[自身拥塞窗口，TCP接受方的接收窗口]

当主机A收到主机B发来的累积确认后，将滑动窗口向前滑动，将已发送并收到确认的这些数据的序号移除窗，由于主机B在累积确认中将自己的接收窗口调整为300，因此主机A相应的将自己的发送窗口也会调整为300。

为了避免死锁，将使用持续计时器，TCP为每一个连接设有持续计时器，只要TCP连接的一方收到了对方的零窗口通知，就启动持续计时器。如果持续计时器超时，就发送一个零窗口探测报文，仅携带一个字节的数据，而对方在确认这个探测报文段时会给出自己现在的接收窗口值，如果接收窗口仍然为0，那么收到这个报文段的一方就重新启动持续计时器。如果接收窗口不是0，那么死锁的局面就可以被打破了。

注意： TCP协议中规定，即使接收窗口为0，那么也必须要接受零窗口探测报文段以及携带紧急数据的报文段。

如果零窗口探测报文也丢失了，那么还能打破死锁的局面吗？

还是可以打破，因为零窗口探测报文段中也有重传计时器，当重传计时器超时后零窗口探测报文会被重传。

5.TCP的拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况叫做拥塞。若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

在计算机网络中的链路容量（即带宽），交换节点中的缓存和处理机等，都是网络的资源。如果出现了拥塞而不进行控制的话，那么整个网络的吞吐量将随输入负荷的增大而下降。

进行拥塞控制的算法有：慢开始，拥塞避免，快重传，快恢复。

由于方向的问题，这些算法的具体细节这里就不在赘述了，如果想要详细了解的话，参考：计算机网络微课堂https://www.bilibili.com/video/BV1c4411d7jb?p=61&vd_source=8eaa56c0356b7a86f2c10571ee56b9f2

6.TCP超时重传时间的选择

超时重传时间的选择是TCP最复杂的问题之一。

一个主机所发送的报文段，可能只经过一个高速率的局域网，也有可能经过多个低速率的网络，并且每个数据报的转发路由还可能不同。正常情况下，超时重传时间应该设为略大于往返时间，但是由于各区域的速率可能不一致，因此将超时重传时间设置为一个固定值是行不通的。

由于方向的问题，这些算法的具体细节这里就不在赘述了，如果想要详细了解的话，参考：计算机网络微课堂https://www.bilibili.com/video/BV1c4411d7jb?p=62&vd_source=8eaa56c0356b7a86f2c10571ee56b9f2

7.TCP的可靠传输（重点）

TCP基于以字节为单位的滑动窗口来实现可靠传输.

然后我们来看看接收方的接受窗口：（假设接收窗口为20）

接收方对于未按序到达的数据（未按序到达可能是有数据丢了也可能是有一些数据在网络中滞留）接收方只能对【按序收到的】数据中的最高序号给出确认； 比如发送方开始发送了31-41序号的数据，而接收方只接收到了 32，33，并没有接收到31，那么此时接受方是不会对其进行发送确认报文的，只有当接收方接受到了31（可能是等待一段时间，超过时间后再向发送方发送请求确认报文ack=31 ...），那么才会对31-33这一段的数据进行接收确认。

如果发送窗口内的序号已经用完了，但是还没有迟迟接受到接收方的确认报文信息，此时发送方是不能再发送新的数据的，如果发送方等待的时间超过了超时重传的时间，就会触发超时重传。

8.TCP的运输连接管理-TCP连接的建立和释放（超重点）

TCP是面向连接的协议，它基于运输连接来传送TCP报文。

tcp连接的建立

TCP运输连接的建立有一下三个阶段：

①建立TCP连接，通过三报文建立TCP链接。

②数据传输阶段。

③释放连接，通过4次挥手来释放连接。

TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

tcp连接的建立需要解决以下三个问题：

①使TCP双方能够确知对方的存在。

②此TCP双方能够协商一些参数。（比如最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量等。）

③使TCP双方能够对运输实体资源（比如缓存大小，连接表中的项目等）进行分配。

TCP使用”三报文握手“建立连接：

最初两端的TCP进程都处于关闭状态。

一开始，TCP服务器的进程首先创建传输控制块，用来存储TCP连接中的一些重要信息（例如TCP连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号），之后TCP服务器就准备接受TCP客户进程的连接请求，此时TCP服务器就进入监听状态，等待客户端发来的请求（tcp服务端是被动的等待来自TCP客户进程的连接请求，而不是主动发起，因此称为被动打开连接）

然后， TCP客户也会创建传输控制块，然后在打算建立连接请求的时候，向服务器发送TCP连接请求，并进入同步已发送状态。（SYN为1表示这是一个tcp连接请求报文段，seq=x 表示作为TCP客户端所选择的初始序号,注意:TCP规定SYN被设置为1的报文段不能携带数据，但要消耗一个序号）

TCP服务进程收到tcp连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。（该报文段首部的同部位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段，序号字段seq被设置了一个初始值y作为tcp服务进程所选择的初始序号，确认号ack的值被设置为x+1，这是对tcp客户进程所选择的初始号的确认（相当于在告诉客户进程你刚刚发送的x序号的数据我接收到了，下次你要向我发送x+1序号的数据），这个报文段也不能携带数据，因为这个是SYN为1的报文段）

TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文，并进入链接已建立状态，ACK为1表明这是一个普通的【tcp确认报文段】，序号字段seq被设置为x+1,这是因为tcp客户进程发送的tcp报文段中的序号为x并且不携带数据，因此第二个报文段的序号为x+1. 注意： TCP规定普通的TCP确认报文段可以携带数据但是要消耗序号，如果不携带数据则不消耗序号， ack= y + 1 表示的是对tcp服务器进程所选择的初始序号的确认（相当于在告诉服务器进程你刚刚发送的y序号的数据我接收到了，下次你要向我发送y+1序号的数据）服务器收到这个确认字段之后，也会进入一个连接已建立状态。此时TCP双方都进入了连接以建立状态。

可以基于已经建立好的TCP连接进行可靠的数据传输。

图解：（与上面的文字解释相对应）

思考：为什么最后tcp客户进程还要发送一个普通的请求确认报文？这是否多余？换句话说，能否使用两报文建立握手？

不多余，不能使用两报文建立握手！看下面一种情况：

TCP发送建立请求连接，但是该报文在某些网络节点长时间滞留了，这必然会造成该报文段的超时重传，假设重传的报文段被TCP服务进程正常接收， TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文，并进入连接已建立状态，请注意，由于我们是改为两报文握手的，因此TCP服务器进程发送完TCP连接请求确认报文后进入的是连接已建立状态，而不像三报文握手那样进入同步已接收状态等待tcp客户进程发送针对tcp连接请求报文段中的普通确认报文段。 tcp客户进程在接收到服务器发来的tcp连接请求确认报文后，进入tcp连接以建立状态，但是不会给TCP服务器进程发送针对该报文段的普通确认报文段。现在TCP双方都处于连接已建立状态，双方可以进行数据的传输，之后可以通过四报文挥手来释放连接。然后TCP双方都进入关闭状态。

一段时间后之前滞留在网络中那个失效的TCP连接请求报文段到达tcp服务进程， TCP服务器进程会误认为这是TCP客户进程又发起了一个新的TCP连接请求，于是会给TCP客户进程发送TCP连接请求确认报文，但是此时TCP客户进程是属于关闭状态，他不会接收到这个请求确认的报文，但是此时TCP服务器进程已经进入连接已建立状态，他认为新的TCP连接已经建立好了，并且会一直等待TCP客户进程发来数据，这将会白白浪费TCP服务器进程所在主机的很多资源。

因此使用三次握手的方式来建立TCP请求连接，是为了防止已经失效的连接请求报文段突然又传到了TCP服务器进程，因而导致请求错误，从而白白浪费TCP所在主机的资源。

图解：

tcp连接的释放

TCP通过 "四报文挥手"来释放连接。

数据传输结束后，双方都可以释放链接。如图，现在TCP客户进程和TCP服务进程都处于连接已建立状态，假设使用TCP客户进程的应用进程通知其主动关闭TCP连接， TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态，该报文段首部中的终止为位为FIN和确认位ACK的值都设置为1，表示这是一个TCP释放报文段，同时也是对之前收到的报文进行确认，同时seq为u它等于tcp客户进程之前已经传过来的数据的最后一个字节的序号加1， TCP规定终值为FIN=1的报文段，即使不携带数据也是要消耗一个序号。确认号ack的值为v,它等于tcp客户进程之前已收到的数据的最后一个字节的序号加1。

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的tcp确认报文段并进入关闭等待状态，该报文段中首部的确认位ACK的值被设置为1表示这是一个普通的tcp确认报文段，序号字段seq=v，它等于tcp服务进程之前已经传送过来的数据的最后一个字节的序号加1（这也与之前收到的TCP连接释放报文段中的确认号匹配），这个ack=u+1,这是对tcp连接释放报文段的确认。 TCP服务器进程这时应该通知高层的应用进程：TCP客户进程要断开与自己的TCP连接。此时从TCP客户进程到TCP服务进程这个方向的连接就释放了。这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送，但TCP服务进程如果还有数据要发送， TCP客户进程仍然要接收，也就是说从TCP服务进程到TCP客户进程这个方向的连接没有关闭，这个状态可能需要持续一段时间， TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报段。

如果使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就会通知其TCP服务器进程释放连接。由于TCP连接释放是TCP客户进程主动发起，因此TCP服务器进程对TCP连接的释放也称为被动关闭连接。 TCP服务器进程发送TCP连接释放报文段并进入最后确认状态，该报文段首部中的终止位FIN和确认为ACK的值都被设置为1,表明这是一个TCP连接释放报文段同时也对之前收到的报文进行确认。现在假定序号seq字段的值为w,这是因为在半关闭状态下， TCP服务进程可能又发送了一些数据。确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，发送普通的TCP确认报文段，之后进入时间等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。序号seq的字段的值被设置为u+1,这是因为TCP客户进程之前发送的TCP连接释放报文虽然不携带数据，但是也要消耗一个序号。确认号ack字段的值设置为w+1,这是对所收到的TCP连接释放报文段的确认（ack=w+1有两重含义表示,第一是表示之前w序号之前以及w的数据都已经被确认接收到，第二重表示请求数据的序号位是要从w+1开始了）。 TCP服务进程收到该报文段后就会进入关闭状态。此时的TCP客户进程还是时间等待状态，需要经过2MSL后才能进入关闭状态。 MLS的意思是最长报文段寿命，RFC793建议为2分钟。之所以这么做是完全从工程上考虑的，对现在的网络来说，这个值取值为两分钟，可能太长了，因此TCP允许不同的实现可根据具体情况使用更小的MSL值. 当2MLS时间正常过后，此时二者连接相关的报文就都会被删除，这样就不会干扰下次来的新的TCP连接请求。

TCP客户进程再发送最后一次确认报文段后为什么不直接进入关闭状态，而是先进入2MLS时间等待状态?

这是因为TCP客户端发送最后一次确认报文后，可能因为网络的延迟或者一些其他情况会导致该请求报文丢失或者是触发服务器的超时重传请求，如果此时TCP客户进程已经关闭了，那么服务器发来的超时重传请求，就不会被客户进程所接收，那么服务器就会处于一直处于最后确认状而无法进入关闭状态，并且还会反复的发送tcp释放连接请求，从而白白浪费服务器很多资源。 所以时间等待状态为2mls可以确保 TCP服务进程可以收到最后一个TCP确认报文段而进入关闭状态。

tcp中保活计时器的作用：

场景：在tcp双方已经建立好连接的情况下，突然客户端所在的主机出现了故障，导致不能发送请求报文，结果就是tcp服务器不能接收到该客户进程发来的请求，但是此时双方这个连接还是建立的状态，此时我们应当采取一些措施，不能让服务器白白等下去，这样会浪费服务器的大量资源。换句话说，就是tcp服务器应该如何发现这种情况呢？使用保活计时器；

六、计算机网络体系---应用层

1.应用层概述

应用层是计算机网络体系结构的最顶层，是设计和建立见算计网络的最终目的。也是计算机网络中发展得最快的部分。

2.客户服务器(C/S)和对等方式(P2P)

客户/服务器

客户和服务器是指通信中所涉及的两个应用进程
客户/服务器方式所描述的是进程之间服务和被服务的关系
客户是服务请求方，服务器是服务提供方
服务器总是处于运行等待状态，并等待客户的服务请求。服务器具有固定端口号(例如HTTP服务器的默认端口号为80)，而运行服务器的主机也具有固定的IP地址

基于C/S方式的应用服务通常是服务集中型的，即应用服务集在网络中比客户计算机少得多的服务器计算机上

由于一台服务器计算机要为多个客户机提供服务，在C/S应用中，常会出现服务器计算机跟不上众多客户机请求的情况。
为此，在C/S应用中，常用计算机群集(或服务器场)构建一个强大的虚拟服务器。

3.域名解析系统DNS

域名解析系统的作用：DNS（Domain Name System）

我们通过输入网址（域名）来访问网页，可实际上计算机间的通信是通过IP地址，所以网址的本质上是IP地址，将网址（域名）与IP地址映射起来就是DNS的作用。

当我们在浏览器栏中输入某个web服务器的域名时，用户主机会首先在自己的DNS高速缓存中查找该域名所对应的IP地址，如果没有找到，则会向网络中某台DNS服务器查询， DNS服务器中有域名和IP地址映射关系的数据库。查询成功之后，DNS服务器就会把刚刚用户主机访问域名所对应的IP地址返回给用户主机，此时用户主机中的浏览器则可以通过web服务器的IP地址对其进行访问了。

因特网是否可以只适用一台DNS服务器？

不能。因为因特网的规模庞大，如果只有一个服务器，一旦该服务器出现故障，那么整个因特网就会瘫痪。

现实中采用层次结构的命名树作为主机的名字(即域名)，并使用分布式的域名系统DNS

DNS使大多数域名都在本地解析，仅少量解析需要在因特网上通信，因此系统效率很高。由于DNS是分布式系统，即使单个计算机出了故障，也不会妨碍整个系统的正常运行

为了提高DNS的查询效率，并减轻根域名服务器的负荷和减少因特网上的DNS查询报文数量，在域名服务器中广泛的使用了【高速缓存】，高速缓存用来存放最近查询过的域名，以及从何处获得域名映射信息的记录。
由于域名到IP地址的映射关系并不是永久不变的，为了保持高速缓存中的内容的正确性，域名服务器应为每项内容设置计时器并删除超过合理时间的线，例如每个项目只存放两天。
不但在本地域名服务器中需要高速缓存，在用户主机中也很需要。许多用户主机在启动时从本地域名服务器下载域名和IP地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到域名时才向域名服务器查询，同理主机也需要保持高速缓存中内容的正确性。

注意：DNS报文使用运输层的UDP协议进行封装，运输层的端口号为53.

4.文件传输协议FTP

将某台计算机中的文件通过网络传送到可能相距很远的另一台计算机中，是一项基本的网络应用，即文件传送。

FTP的常见用途是在计算机之间传输文件，尤其是用于批量传输文件。FTP的另一个常见用途是让网站设计者将构成网站内容的大量文件批量上传到他们的Web服务器。

文件传送协议FTP是因特网上使用得最广泛的文件传输协议。

FTP提供交互式的访问，运行客户指明文件的类型与格式(如指明是否使用ASCII码)，并允许文件具有存取权限(如访问文件的用户必须经过授权，并输入有效的口令)。
FTP屏蔽了各计算机系统的细节，因而适合于在异构网络中任意计算机之间传送文件

用于传送控制命令的TCP连接在整个会话过程都保持开启状态。
用于传送控制命令的TCP连接在整个会话过程都保持开启状态。

比如常见的一个基于FTP封装的文件传输软件: filezilla

5.万维网

1.万维网的概述

万维网并非某种特殊的计算机网络。它是一个大规模的、联机式的信息储藏所，是运行在因特网上的一个分布式应用。万维网利用网页之间的超链接将不同网站的网页链接成一张逻辑上的信息网。

浏览器最重要的部分是渲染引擎，也就是浏览器内核。负责对网页内容进行解析和显示：

不同的浏览器内核对网页内容的解析也有不同，因此同一网页在不同内核的浏览器里显示的效果可能不同
网页编写者需要在不同内核的浏览器中测试网页显示效果
为了方便地访问在世界范围的文档，万维网使用统一资源定位符URL来指明因特网上任何种类"资源"的位置
为了方便地访问在全世界范围的文档，万维网使用的是统一资源定位符URL来指明因特网上任何种类资源的位置。URL的一般形式由以下四个部分组成

2.超文本传输协议http

HTTP定义了浏览器(即万维网进程)怎样向万维网服务器请求万维网文档，以及万维网服务器怎样把万维网文档传送给浏览器.

Cookie提供了一种机制使得万维网服务器能够"记住"用户，而无需用户主动提供用户标识信息。也就是说，Cookie是一种对【无状态的HTTP进行状态化】的技术。

大致描述：当用户第1次向一个服务器发起HTTP请求的时候，服务器在接收到该请求后，会为该客户生成一个唯一的cookie识别码，并且会把这个cookie写在响应报文里面返回给用户主机，用户主机接收之后，浏览器会将cookie的信息存入一个文件当中（客户浏览器中的cookie文件大小是会增长的，服务器会将用户访问服务器的记录信息携带在cookie中，然后以响应报文的形式返回给客户端，客户端接收后会对本地的cookie文件记录的追加），那么当下一次用户再次访问这个服务器的时候，用户就可以在请求头中携带cookie去访问服务器，服务器就可以根据cookie的识别码，然后识别出用户，并返回用户的【个性化】网页。

4.万维网缓冲与代理服务器

如果原始服务器中的文档已经修改，但是代理服务器中仍然有缓存，那么主机访问文档时是否会访问到未修改的文档从而发送错误呢？

实际上，原始服务器会为每个响应的对象设定一个修改时间字段和一个有效日期字段。当主机的请求到达代理服务器时，若代理服务器中的文档未过期则直接返回响应报文，否则代理服务器向原始服务器发送请求，这次请求的报文中的头部中有If-modified-since字段，记录了上次文档的修改时间，原始服务器根据该文档的修改时间就可以判断出代理服务器中存储的该文档是否与自己存储的该文档一致，如果文档的修改时间一致，说明文档没有发送变化，因此原始服务器返回一个不包含实体的响应，状态码为304，然后代理服务器重新更新该文档的有效日期，然后再将该文档封装在响应报文中发回给主机。如果文档的修改时间不一致，原始服务器会给代理服务器发送封装有该文档的响应报文，这样代理服务器就更新了文档，然后将更新后的该文档封装在响应报文中发回给主机。

计算机网络之运输层和应用层学习笔记

五、计算机网络体系---运输层

1.运输层概述（重点）