计算机网络知识点总结

一. OSI与TCP/IP各层的结构与功能,都有哪些协议?

OSI，TCP/IP，五层协议的体系结构，以及各层协议

1.1应用层

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用
HTTP协议

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的
WWW（万维网） 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。

1.2运输层

传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。

传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
用户数据协议UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

1.3网络层

实现两个主机系统之间的数据透明传送.网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。
主要协议有:

IP协议（Internet Protocol，因特网互联协议）;

ICMP协议（Internet Control Message Protocol，因特网控制报文协议）;

ARP协议（Address Resolution Protocol，地址解析协议）可看成是跨网络层和链路层的协议;

RARP协议（Reverse Address Resolution Protocol，逆地址解析协议）。

1.4数据链路层

1> 数据链路层为网络层提供可靠的数据传输；

2> 基本数据单位为帧；

3> 主要的协议：以太网协议；

4> 两个重要设备名称：网桥和交换机。

1.5物理层

该层为上层协议提供了一个传输数据的可靠的物理媒体。简单的说，物理层确保原始的数据可在各种物理媒体上传输.

信息在网络中传输过程

1、某进程(也就是在应用层)准备好待传输数据，若目的地址是域名则要先通过DNS解析成IP地址

2、交付到运输层(TCP/UDP层)，运输层对数据进行适当的分组等操作，后对每一个分组数组加上首部形成报文段(或用户数据报)首部包括源地址、源端口、目的地址、目的端口和一些其他的诸如校验和等数据

3、交付到网际层(IP层)，对分组数据加上首部形成IP数据报，首部包括源地址、目的地址(跟运输层的目的地址不同，运输层的目的地址是数据要传送的最终地址，而该目的地址是通过路由表信息得出，是该数据下一步该转移的目的计算机)和校验和等数据

4、交付到数据链路层(mac层)，先是对把数据封装成帧(也就是添加首部[SOH]和尾部[EOT])，然后进行透明传输(也就是封装的数据里面，如果出现首部SOH和尾部EOT这样的数据，对其进行转义，也就是加上ESC转义字符，这种方法称为字节/字符填充)

5、交付到物理层，根据数据链路层的mac知道要传输到目的计算机，通过特定的传输介质传送到下一个地址

6、若源主机与最终目的主机在同一个网段，则该地址是最终的目的主机，开始接收数据，进入第7步骤，若源主机和最终目的主机不在同一个网段，进入第11步骤

7、交付到数据链路层，对数据进行卸装，该层会对接收的数据进行差错检测，有差错的数据都会被丢弃

8、交付到IP层，解帧校验

9、交付到运输层，在该主机上，根据端口找到对应的应用，当使用的TCP协议时，提供一种面向连接的可靠的传输服务，可以说是建立了一个虚拟通道，源主机的数据通过该虚拟通道进行传输；若是使用的UDP协议时，提供一种面向的非连接的尽最大努力的不可靠的传输服务，数据传输快，但是无法保证数据100%传输。

10、建立了传输连接后，应用开始接收数据，发送方数据和接收方都必须满足相同的标准应用层协议，如http、ftp、smtp等，通过标准协议应用即可正确的接收源主机发送过来的数据。

11、该计算机不是最终主机，那该计算机就是路由器也就是用于转发分组数据的中转站，首先接收数据的处理同步骤7和8一样，然后接下来的流程又是如同步骤3,

12、如此循环直至找到最终主机，将数据传送到目的应用

二 .TCP 三次握手和四次挥手

2.1TCP三次握手和四次挥手详解

首先了解TCP首部结构
1.源端口和目的端口，各占2个字节，分别写入源端口和目的端口；
2.序号, 占4个字节， TCP连接中传送的字节流中的每个字节都按顺序编号.
3.确认号，占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。
4.数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
5.确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
6.同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
7.终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

1.TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
2.TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3.TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
4.TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
5.当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

1.客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过 2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6.服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

2.2为什么是三次握手和四次挥手

三次握手:为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误.(如果在连接过程中,客户端发出的连接请求报文段在网络中滞留,在连接释放后的某个时间发送到了服务端,服务端以为是建立连接请求,于是发出确认,如果不是三次握手,服务端就会一直等着客户端发来数据,造成网络资源浪费,三次握手就很好的解决了此问题.)
四次挥手:例子:举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

2.3.为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

2.4 TCP,UDP 协议的区别

2.5 TCP 协议如何保证可靠传输

1.应用数据被分割成 TCP 认为最适合发送的数据块。
2.TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3.校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4.TCP 的接收端会丢弃重复的数据。
5.流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6.拥塞控制： 当网络拥塞时，减少数据的发送。
7.ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8.超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

三.在浏览器中输入url地址 ->> 显示主页的过程

总体来说分为以下几个过程:

1.DNS解析
2.TCP连接
3.发送HTTP请求
4.服务器处理请求并返回HTTP报文
5.浏览器解析渲染页面
6.连接结束

四.cookie和session的区别

1、数据存放位置不同：
cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、安全程度不同：
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
3、性能使用程度不同：
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。
4、数据存储大小不同：
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。
5、会话机制不同
session会话机制：session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。
cookies会话机制：cookie是服务器存储在本地计算机上的小块文本，并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端，浏览器解析cookie并将其保存为本地文件，该文件自动将来自同一服务器的任何请求绑定到这些cookie。