1、计算机网络
1.1 OSI与TCP/IP各层的结构与功能,都有哪些协议?
1.1.1 应用层
应用层(application-layer）的任务是 通过应用进程间的交互来完成特定网络应用
应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则
对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如 域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议 等等
我们把应用层交互的数据单元称为报文
HTTP协议：超文本传输协议是互联网上应用最为广泛的一种网络协议。所有的www（万维网）文件都必须遵守这个标准。设计HTTP最初的目的就是为了提供一种发布和接收HTML页面的方法
1.1.2 运输层
运输层(transport layer)的主要任务就是 负责向两台主机进程之间的通信提供通用的数据传输服务，应用进程利用该服务传送应用层报文
“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务
由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程
运输层主要使用以下两种协议：
传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务
用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）
1.1.3 网络层
在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能要进过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点，确保数据及时传送。
在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在TCP/IP体系结构中，由于网络层使用IP协议，因此，分组也叫 IP数据报，简称 数据报
互联网是由大量的异构网络通过路由器互相连接起来的。互联网使用的网络层协议是无连接的网络协议和许多路由选择协议，因此互联网的网络层也叫做网际层或IP层
注意：不要把运输层的“用户数据报UDP”和网络层的“IP数据报”弄混。另外，无论那一层的数据单元，都可以笼统的用分组来表示
互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Protocol）和许多路由选择协议，因此互联网的网络层也叫做 网际层 或 IP层
1.1.4 数据链路层
数据链路层通常简称为链路层。两台主机之间的数据传输通常在一段一段的链路上进行传送的，这就需要专门的链路层协议
在两个相邻的节点之间传送数据时，数据链路层将网络层交下来的 IP数据报组装成帧，在两个相邻节点间的链路上传送帧，每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制等）
在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始，从哪个比特结束，这样，数据链路层在收到一个帧以后，就可以从中提出数据部分，上交给网络层。
控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单的丢弃了这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检查错误，还要纠正错误），那么就需要采用 可靠性传输协议 来纠正出现的差错，这种方法会使链路层的协议稍微复杂一些
1.1.5 物理层
在物理层上传送的数据单位是比特。物理层的作用是实现相邻计算机节点之间 比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体的传输介质是什么。透明传送比特流 标示经实际电路传送之后，比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的
1.2 TCP三次握手和四次挥手
1.2.1 三次握手
为了准确无误的把数据送达目标处，TCP协议采用了三次握手策略
基本流程
客户端-发送带有SYN标志的数据包-一次握手-服务端
服务端-发送带有SYN/ACK标志的数据包-二次握手-客户端
客户端-发送带有ACK标志的数据包-三次握手-服务端
为什么要三次握手
三次握手的目的是建立可靠的通信通道，说到通讯，简单来说就是数据的发送和接收，而三次握手最主要的目的就是双方确认自己与对方的发送和接收是正常的
第一次握手：Client什么都不能确认，Server确认了对方发送正常，自己接收正常
第二次握手：Client确认了，自己发送、接收正常，对方发送接收正常，Server确认了：自己接收正常，对方发送正常
第三次握手正常：Client确认了：自己发送、接收正常，对方发送、接收正常，Server确认了：自己发送、接收正常，对方发送、接收正常
为什么要传回SYN
接收端传回发送端所发送的SYN是为了告诉发送端，我接收到的信息确实就是你所发送的信号了
SYN是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发送一个SYN消息，服务器使用SYN-ACK应答表示接收到了这个消息，最后客户机再以ACK消息响应，这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递
ACK（Acknowledgement：确认字符，在数据通信传输中，接收站发送给发送站的一种传输控制字符。它表示确认发送来的数据已经接受无误）
SYN：同步序列编号（Synchronize Sequence Numbers）。是TCP/IP建立连接时使用的握手信号
传了SYN为什么还需要传递ACK
双方通信无误必须是两者互相发送信息都无误。传了SYN，证明发送方到接收方的通道都没有问题，但是接收方到发送方的通道还需要ACK信号来进行严重
1.2.2 四次挥手
断开一个TCP连接需要四次挥手
客户端-发送一个FIN，用来关闭客户端到服务器的数据传送
服务器-收到这个FIN，他返回一个ACK，确认序号为收到的序号加1，和SYN一样，一个FIN将占用一个序号
服务器关闭与客户端的连接，发送一个FIN给客户端
客户端-发回ACK报文确认，并将确认序号设置为收到序号加1
为什么需要四次挥手？
任何一方都可以在数据传输结束之后发出连接释放的通知，待对方确认之后进入半关闭的状态，当一方也没有数据在发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接
1.3 TCP、UDP
1.3.1 TCP、UDP区别
UDP在传输数据之前不需要先建立连接，远程主机在接收到UDP报文之后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式（一般用于即使通信），比如：QQ语言、QQ视频、直播
TCP提供面向连接的服务。在传送数据之前必须先建立连接，数据传输结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的，面向连接的传输服务（TCP的可靠性体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传输完之后，还会断开连接用来节约系统资源），这难免会增加很多的开销，如确认、流量控制、计时器以及连接管理等，这不仅使协议数据单元的首部增加很多，还要占用许多处理机资源。TCP一般用于文件传输、发送和接收邮件、远程登陆等场景
1.3.2 TCP如何保证可靠传输
应用数据被分割成TCP认为最合适发送的数据块
TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层
校验和：TCP将保持它的首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化，如果收到的段和检验和有差错，TCP将丢弃这个报文和不确认收到此报文段
TCP的接收端会丢弃重复的数据
流量控制：TCP连接的一方会有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收缓冲区能收纳的数据，当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用流量控制协议是可变大小的滑动窗口协议（TCP使用滑动窗口协议实现流量控制）
拥塞控制：当网络拥塞时，减少数据的发送
ARQ协议：也是为了实现可靠性传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认，在收到确认后再发下一个分组
超时重传：当TCP发出一个段之后，他启动一个定时器，等待目的端确认收到这个报文段，如果不能即使收到一个确认，将重发这个报文段
1.3.3 ARQ协议
自动重传请求（Automatic Repeat-Request）是osi模型中数据链路层和传输层的错误纠正协议之一。他通过使用 确认 和 超时 这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方发送一段时间后没有收到确认帧，它通常会重新发送。
ARQ包括停止等待ARQ协议和连续ARQ协议
停止等待ARQ协议
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对象确认（回复ACK）。如果过了一段时间（超过一段时间后），还是没有收到ACK确认，说明没有发送成功，需要重新发送，直到确认后在发下一个分组
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认
优点：简单
缺点：信道利用率低，等待时间较长
无差错情况：发送方发送分组，接收方在规定时间内收到并且回复确认，发送方再次发送
出现差错情况（超时重传）：停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了
确认丢失和确认迟到：确认消息在传输过程丢失。确认消息在传输过程中迟到。
连续ARQ 协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了
优点：信道利用率高、容易实现，即使确认丢失也不必重传
缺点：不能向发送方反映出接收方已经正确的收到所有分组的信息。比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。
1.3.4 滑动窗口和流量控制
TCP利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证了接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据
1.3.5 拥塞控制
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要被破坏，这种情况就叫做 拥塞。
拥塞控制 就是为了防止过多的数据注入到网络之中，这样就可以使网络中的路由器或链路不至于过载。
阻塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。阻塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是 点对点 通信量的控制，是个端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便接收端来得及接收
为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个
TCP的拥塞控制采用了 四种算法 ，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生
1.4 在浏览器中输入URL到显示主页的全过程
1.4.1 打开一个网页会使用到哪些协议
1.4.2 过程
DNS解析
TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束
1.4.3 URI和URL的区别？
URI是统一资源标志符，可以唯一标识一个资源
URL是统一资源定位符，可以提供该资源的路径，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何llocate这个资源
URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息
1.5 HTTP协议
1.5.1 各种协议与HTTP协议之间的关系
1.5.2 HTTP常连接和短连接
《HTTP长连接、短连接究竟是什么？》
短链接：
在HTTP/1.0中默认使用短连接，也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接
当客户端浏览器访问的某个HTML或其他类型的web页中包含有其他的web资源（如 JavaScript文件、图像文件、CSS文件），每次遇到这样一个web资源，浏览器就会重新建立一个HTTP会话
长连接：
从HTTP/1.1起，默认使用长连接，用以保持连接的特性，使用长连接的HTTP协议，会在响应头中加入这行代码：
Connection:keep-alive
1
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间
实现长连接需要客户端和服务端都支持长连接
1.5.3 注意
HTTP的长连接和短连接，实质上是TCP协议的长连接和短连接
1.5.4 HTTP1.0和HTTP1.1的主要区别是什么？
长连接和短连接：
在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。
HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求
错误状态响应码：
在HTTP1.1中新增了24个错误状态响应码。如：409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除
缓存处理：
在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准
HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略
带宽优化及网络连接的使用：
HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能
HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接
1.6.5 HTTP与HTTPS的区别？
端口
HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443
安全性和资源消耗
HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份
HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密
HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源
相关解释：
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等
1.6 Cookie、Session
1.6.1 HTTP是不保存状态的协议，如何保存用户状态？
HTTP是一种不保存状态即 无状态（stateless）协议，也就是说HTTP协议不对请求和响应之间的通信状态进行保存
Session机制的存在就是为了解决这个问题，Session的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）
在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪
1.6.2 Cookie 被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面
1.6.3 Cookie的作用是什么？和Session有什么区别？
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样
Cookie一般用来保存用户信息
我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了
一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)
登录一次网站后访问网站其他页面不需要重新登录
Session 的主要作用就是通过服务端记录用户的状态
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了
Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端
Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密
————————————————
版权声明：本文为CSDN博主「houbj的博客」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_31852205/article/details/113104355
标签：发送,HTTP,协议,确认,TCP,计算机网络,连接 来源： https://blog.csdn.net/weixin_47327232/article/details/114855102
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。