栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 软件开发 > 后端开发 > Java

计算机网络基础知识点归纳(计算机网络基础学什么)

Java 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

计算机网络基础知识点归纳(计算机网络基础学什么)

文章目录

HTTP 协议

概述特点Session 机制

session 过期如何获取 session如何销毁 sessionsession 有哪些主要的方法 API cookie 机制

VS Session 请求报文响应报文响应流程URI VS URLHTTP VS HTTPSHttpServletResponse 和HttpServletRequest

Response 常见应用Request 常见方法 请求转发和重定向 OSI 模型TCP / IP 模型TCP 三次握手、四次挥手TCP VS UDPTCP 可靠传输滑动窗口拥塞控制

四种算法

HTTP 协议 概述

在网络上的不同计算机之间必须使用相同的网络协议才能进行通信,HTTP(超文本传输协议)协议就是用于规范客户端浏览器和服务器以什么样的格式进行通信数据交互的,是属于应用层的面向对象的协议,适用于分布式超媒体信息系统,HTTP 协议中的数据又叫报文。

HTTP协议由请求和响应构成,是一个标准的客户端服务器模型,也是一个无状态的协议。

特点

    支持客户端 / 服务器软件(C / S)模式、浏览器 / 服务器软件(B / S)模式。

    简单快速灵活:客户端向服务器请求服务时,只需要传送请求方法(常有 get、post)和路径(URL)。由于 HTTP 协议简单,使得 HTTP 服务器的程序规模小,因而通信速度很快。

    无连接:限制每次连接只处理一个请求,服务器处理完客户请求并且收到客户应答,即断开连接。

    在 HTTP / 1.0 中默认使用短连接:客户端和服务器每进行一次 HTTP 操作就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源(如 Javascript 文件、图像文件、CSS 文件等),每遇到这样⼀个 Web 资源,浏览器就会重新建立一个 HTTP 会话。

    从 HTTP / 1.1 起默认使用长连接:保持连接特性,使用长连接的 HTTP 协议,会在响应头加⼊这行代码:connection:keep-alive。在使用长连接的情况下,当⼀个网页打开完成后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,客户端再次访问这个服务器时,会继续使用这⼀条已经建立的连接。Keep-Alive 不会永久保持连接,它有⼀个保持时间,可以在不同的服务器软件(如 Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

    无状态:指协议对于事务处理没有记忆能力,意味着如果后续处理需要前面的信息,则它必须重传,可能导致每次传送的数据量增大。

    问题:HTTP 是无状态协议,怎么保存用户信息?

    ==答:==Session 机制。Session 机制的存在就是为了解决这个问题,其主要作用就是通过服务端记录用户的状态信息。典型的场景是购物车,当要添加商品到购物车时,系统不知道是哪个用户操作的,但是服务端给特定的用户创建特定的 Session 之后,就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session,过了时间限制,就会销毁该 Session)。在服务端保存 Session 的方法很多,最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。

    问题:既然 Session 存放在服务器端,如何实现 Session 跟踪?

    ==答:==大部分情况下,通过在 cookie 中附加一个 sessionID 来跟踪。

    问题:cookie 被禁用怎么办?

    ==答:==最常用的就是利用 URL ,把 sessionID 直接附加在 URL 路径的后面。

Session 机制

服务器状态管理技术,将用户状态信息保存在服务器端,是 SUN 公司定义的一个接口。

Session 机制是用来解决 HTTP 无状态的问题。本质上是在服务器端开辟一个空间(容器),这个容器中有一个唯一标识 sessionID 送给客户端,客户端每次请求都会携带这个标识。

类似于一个散列表文件(一个 Map),里面的 key 存储的是用户的 session 唯一标识 sessionID 。

用户向服务器发起请求时,服务器检测是否带有 sessionID,若没有则创建容器,再把这个 sessionID 送回给客户端;若有则去检测容器并给客户端使用。

同一个客户端(同一个浏览器)在一段时间内 session 标识是不变的。

session 过期

客户端与服务器端连接时,长时间没有动作或超过程序员设置的时间戳,此时会话 session 会被清空或回收,从服务器内存中清除,之后该 session 就失效了,Tomcat中默认失效时间是 20 分钟。

如何获取 session

Request.getSession() ,该方法有两个含义:1.服务器发现是一个新的请求则开辟一个新的 session;2.若请求中有 session 标识,判断 session 标识是否失效,若失效则返回一个新的 session,否则返回原来的 session。

如何销毁 session
    主动销毁:session.invalidate();设置生命时间周期:设置无操作间隔时间,超时则销毁session.setMaxInactiveInterval(1000*5*60);当用户关闭浏览器时,sessionId 的信息就会丢失,虽然服务 session 还在,但是无法访问到 session 中的数据。
session 有哪些主要的方法 API
    setAttribute(String key,Object value):采用 key / value 存储模式Object getAttribute(String key):获取值removeAttribute(String key):移除
cookie 机制

在 Session 机制出现之前基本上所有网站都采用 cookie 来跟踪会话(一个用户的所有请求操作都属于同一个会话)。因此,cookie 也是解决 HTTP 协议无状态的问题(一旦数据交换完毕,客户端与服务器端的连接就会关闭,再次交换数据需要建立新的连接,也就是无法跟踪会话)。

cookie 一般用来在客户端保存用户信息,比如在 cookie 中保存已经登录过的用户信息,下次访问网站时,页面可以自动把之前登录的一些基本信息填了;一般的网站都会有保持登录功能(下次再访问网站时不需要重新登录),这是因为用户登录的时候存放了一个 Token 在 cookie 中,下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑,重新登录一般要将Token重写);登录一次网站后访问网站其他页面不需要重新登录。

cookie 实际上就是一小段的文本信息,我们可以用加密来解决它的信息不安全问题。cookie 对象使用 key-value 的形式保存用户状态,一个 cookie 对象保存一个属性对,一个 request 或 response 同时使用多个 cookie。

cookie 生命周期案例:可以永久保存(永久登录),方法是把登录信息如账号、密码等保存在 cookie 中,并控制 cookie 的有效期,下次访问时再验证 cookie 中的登录信息即可。缺点是与数据库相比,不安全。

VS Session
    cookie 数据保存在客户端(浏览器端),Session 数据保存在服务器端;Session 安全性更高,如果要在 cookie 中存储⼀些敏感信息,不要直接写入 cookie 中,将 cookie 信息加密,使用时再去服务器端解密。
请求报文

由 4 部分组成:请求行(request line)、请求消息头(headers)、空行(blank line)、请求体(request body)

    请求行:位于请求消息第一行,包括请求方式、资源路径、所使用的HTTP协议版本 3 部分

    请求方式:HTTP 协议中主要是 GET 和 POST

    GET:当用户在浏览器地址栏中直接输入某个 URL 地址或单击网页上的一个超链接时,浏览器默认使用 GET 方式发送请求。

    POST:若网页上的 form 表单的 method 属性设置为 “post”,那么就会以 POST 方式发送请求。

    注意:GET 是读数据,POST 是存数据,但是 GET 可以直接将参数写在 URL 中(即 POST 的信息作为 HTTP 请求的内容,而 GET 是在 HTTP 头部传输的)。由于 GET 请求方式的参数信息都会在 URL 地址栏里明文显示,而 POST 请求方式传递的参数隐藏在实体内容中,用户不可见,较为安全。因此在实际开发中,大多使用 POST 。

    请求消息头:由关键字/值对组成,每行一对。作用是通知服务器有关于客户端请求的信息。

    空行:在最后一个请求头之后,发送回车符和换行符,通知服务器一下不再有请求头。

    请求体:其内容就是请求数据,请求数据不在 GET 方法中使用,而是在 POST 方法中使用。POST 方法适用于需要客户填写表单的场合。

响应报文

由 4 部分组成:状态行(status line)、相应消息头(Headers)、空行(blank line)、响应体(response body)

响应流程

在浏览器中输入一个 URL 地址,直到页面显示,经历了以下步骤:

    浏览器根据域名查找其 IP 地址,使用 DNS 协议解析;

    浏览器通过 TCP 协议与 web 服务器建立连接,向服务器发送一个 HTTP 请求;

    建立 TCP 连接时,需要在网络层使用 IP 协议发送数据;IP 数据包在路由器之间,路由选择使用 OPSF 协议;路由器在与服务器通信时,使用 ARP 协议将 IP 地址转换为 MAC 地址。在 TCP 建立完成后,使用 HTTP 协议访问。

    web 服务器处理请求并返回 HTTP 报文;

    服务器发回一个 HTML 响应;

    浏览器开始显示 HTML ;

    连接结束。

URI VS URL

URI,Uniform Resource Identifier,是统一资源标志符,可以唯一标识一个资源;

URL,Uniform Resource Location,是统一资源定位符,可以提供该资源的路径,是一种具体的 URI,它不仅唯一标识资源,还提供了定位该资源的信息。

(URI 的作用像身份证号,URL 的作用像家庭住址)

HTTP VS HTTPS

    URL: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 等。

HttpServletResponse 和HttpServletRequest

这两个是 Java 专门处理 HTTP 请求的类,HttpServletResponse 代表服务器的响应,HttpServletRequest 代表客户端的请求。

Response 常见应用
    实现请求重定向:一个 Web 资源收到客户端请求后,通知客户端去访问另一个 Web 资源实现方式:response.sendRedirect()
Request 常见方法

HttpServletRequest 类的作用:每次只要有请求进入 Tomcat 服务器,服务器就会把请求过来的 HTTP 协议信息解析好封装到 Request 对象中,然后传递到 Service 方法(doGet 或 doPost)中供后端使用。我们可以通过 HttpServletRequest 对象获取到请求的所有信息。

    获取客户端信息:

    方法名作用
    getRequestURL返回请求的完整URL
    getRequestURI返回请求的资源名部分
    getQueryString返回请求的参数部分
    getPathInfo返回URL中的额外路径信息(位于Servlet路径之后和查询参数之前的内容,以/开头)
    getRemoteAddr返回客户机使用的IP
    getRemoteHost返回客户机使用的主机名
    getRemotePort返回客户机使用的网络端口号
    getLocalAddr返回web服务器的IP
    getLocalName返回web服务器的主机名

    获取客户端请求参数(客户端提交的数据)

    方法名作用
    getParameter(String name)获取前端表单单个元素name对应的value值
    getParameterValues(String name)获取前端表单多个标签同名name对应的所有value值
    getParameterNames(String name)获取前端表单所有标签元素name的对应的所有value值
    getParameterMap返回Map型的值
请求转发和重定向
    请求转发:服务器将未处理完的请求直接交给后端另一块模块处理,整个请求被处理完之后才返回结果给客户端。

使用:request.getRequestDispatcher().forward();

    重定向:服务器告诉客户端(给了客户端一个 sessionID)再去请求另一个页面 / 资源。

    使用:response.sendRedirect();

OSI 模型
    应用层表示层会话层传输层网络层数据链路层物理层
TCP / IP 模型
    应用层:HTTP、SMPT(简单电子邮件传输)、FTP(文件传输)传输层:TCP、UDP网络层:IP数据链路层
TCP 三次握手、四次挥手

三次握手:客户端请求服务器连接。

    客户端发送一个带有 SYN =1 标志的请求,同时随机生成一个 seq 序列号;

    服务端收到后,发送一个确认标志 ACK =1 和确认序列号 ack = seq+1,同时发送一个 SYN =1 标志以及序列号 seq 给客户端。这时,对客户端来说,收发消息都没有问题。但是,对服务器来说,仅仅是收到了客户端的连接请求,不能确认客户端是否收到了确认回应;

    第三次握手,客户端发送 ACK 确认标志以及序列号 ack。

四次挥手:客户端请求服务器断开连接。

    客户端发送一个 FIN =1 的标志以及序列号 seq 给服务端;

    这个时候服务端可能还有数据没有传输结束,所以只是给客户端发送一个确认标志 ACK 和序列号;

    等传输完所有数据之后,服务器会发送一个 FIN =1 标志以及 seq 序列号给客户端,表示可以断开连接;

    客户端再发送一个确认标志 ACK = 1 以及序列号给服务端,断开连接。

TCP VS UDP

TCP:面向连接,可靠传输,字节流传输形式,效率低,所需资源多,要求数据安全时使用;

UDP:无连接,不可靠,数据报文段传输形式,效率高,所需资源少,要求通信速度高时使用。

TCP 可靠传输

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

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

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

拥塞控制

在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏,这种情况叫拥塞。

拥塞控制是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。

拥塞控制要做的都有一个前提,就是网络能够承受现有的网络负 荷。拥塞控制是全局性的过程,涉及所有的主机、路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

为了进行拥塞控制,TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的⼀个。

四种算法

TCP 的拥塞控制采用的算法:慢开始、拥塞避免、快重传和快恢复。

    慢开始:思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。较好的方法是先探测,即由小到大逐渐增大拥塞窗口数值。 cwnd 初始值为 1,每经过一个传播轮次,cwnd 加倍。

    拥塞避免:思路是让拥塞窗口 cwnd 缓慢增大,即每经过⼀个往返时间 RTT 就把发送方的 cwnd + 1。

    快重传和快恢复 FRR:能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停,在暂停的这段时间内,没有新的或复制的数据包被发送;有了 FRR,如果接收机接收到不按顺序的数据段,它会立即给发送机发送重复确认,如果发送机接收到三个重复确认,它会假定数据段丢失了,并立即重传这些丢失的数据段,不会因为重传时要求的暂停被耽误。

    当有单独的数据包丢失时,FRR 能最有效地工作;当有多个数据信息包在某段很短的时间内丢失时,它则不能很有效地工作。

转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/775976.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号