目录

一、OSI模型、TCP/IP模型(各层协议)

二、TCP和UDP的区别

三、TCP可靠传输的原理:序列号与确认号、重传机制、流量控制、拥塞控制、首部检验和

四、TCP三次握手,四次挥手过程

五、timewait 和 closewait

六、HTTP:报文格式、1.0 1.1 2.0、状态码,无状态解决(Cookie,Session)

七、HTTPS:CA证书、对称加密、非对称加密

八、HTTP 与 HTTPS的区别

九、在浏览器中输入URL到显示页面的过程

十、DNS解析过程、原理

十一、post与get的区别

十二、SQL注入

十三、XSS攻击

十四、粘包和拆包

十五、forward 和 redirect

十六、数字签名、数字证书

十七、滑动窗口

十八、停止等待协议、ARQ 协议

十九、CSMA/CD

二十、PPP

二十一、IPv4、IPv6

二十二、ARP

二十三、ICMP、IGMP

二十四、RIP

二十五、OSPF

二十六、BGP

二十七、SSH

二十八、DHCP

二十九、大端,小端

三十、IP地址和MAC地址

三十一、TCP建立连接后,影响传输速度的因素

三十二、syn flood

三十三、传输层为什么需要端口号

三十四、Nagle 和 Clark

三十五、如果使用UDP协议,如何保证可靠

三十六、IPv4分类

三十七、GET请求中URL编码的意义

三十八、多播

三十九、为什么有了mac地址还要用ip地址/为什么有了ip地址还要mac地址

四十、http3.0



一、OSI模型、TCP/IP模型(各层协议)

(1)OSI与TCP/IP

应用层

        应用层(application-layer)的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程(进程:主机中正在运行的程序)间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多,如域名系统DNS,支持万维网应用的HTTP协议,支持电⼦邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文
        域名系统
域名系统(Domain Name System缩写 DNSDomain Name被译为域名)是因特网的⼀项核心服务,它作为可以将域名和IP地址相互映射的⼀个分布式数据库,能够使⼈更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。(百度百科)例如:⼀个公司的 Web 网站可看作是它在网上的们户,而域名就相当于其门牌地址,通常域名都使用该公司的名称或简称。例如上面提到的微软公司的域名,类似的还有:IBM 公司的域名是 www.ibm.comOracle 公司的域名是 www.oracle.comCisco公司的域名是 www.cisco.com 等。
        HTTP协议
                超⽂本传输协议(HTTPHyperText Transfer Protocol)是互联网上应用最为广泛的⼀种网络协议。所有的 WWW(万维网) 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供⼀种发布和接收 HTML 页面的⽅法。(百度百科)

运输层

        运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服。应用进程利用该服务传送应用层报⽂。通用的”是指并不针对某⼀个特定的网络应用,而是多种应用可以使用同⼀个运输层服务。由于⼀台主机可同时运行多个线程,因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务,分用和复用相反,是运输层把收到的信息分别交付上面应用层中的相应进程。
        运输层主要使用以下两种协议:
1. 传输控制协议 TCPTransmission Control Protocol--提供面向连接的,可靠的数据传输服务。
2. 用户数据协议 UDPUser Datagram Protocol--提供⽆连接的,尽最大努力的数据传输服务(不保证数据传输的可靠性)。
③网络层
网络层负责为分组交换网上的不同主机提供通信服务。
        在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。 在发送数据时,网络层把运输层产⽣的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构 中,由于网络层使用 IP 协议,因此分组也叫 IP 数据报 ,简称 数据报
这里要注意:不要把运输层的“用户数据报 UDP ”和网络层的“ IP 数据报弄混。另外,⽆论是哪⼀层的数据单元,都可笼统地用分组来表示。
这里强调指出,网络层中的“网”⼆字已经不是我们通常谈到的具体网络,而是指计算机网络体系结构模型中第三层的名称
互联网是由大量的异构(heterogeneous)网络通过路由器(router)相互连接起来的。互联网使用的网络层协议是无连接的网际协议(Intert Protocol)和许多路由选择协议,因此互联网的网络层也叫做⽹际层IP

数据链路层

        数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输,总是在一段一段的链路上传送的,这就需要使用专门的链路层的协议。 在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧。每⼀帧包括数据和必要的控制信息(如同步信息,地址信息,差错控制等)。
在接收数据时,控制信息使接收端能够知道⼀个帧从哪个比特开始和到哪个比特结束。这样,数据链路层在收到⼀个帧后,就可从中提出数据部分,上交给网络层。
控制信息还使接收端能够检测到所收到的帧中有误差错。如果发现差错,数据链路层就简单地丢 弃这个出了差错的帧,以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错(这就是说,数据链路层不仅要检错,而且还要纠错),那么就要采用可靠性传输协议来纠正出现的差错。这种⽅法会使链路层的协议复杂些。

物理层

在物理层上所传送的数据单位是比特。
        物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上面的数据链路层不必考虑网络的具体传输介质是什么。
“透明传送比特流”表示经实际电路传送后的比特流没有发生变化,对传送的比特流来说,这个电路好像是看不见的。
在互联网使用的各种协中最重要和最著名的就是 TCP/IP 两个协议。现在⼈们经常提到的TCP/IP并不⼀定单指TCPIP这两个具体的协议,而往往表示互联网所使用的整个TCP/IP协议族。
(2)OSI七层

(3)各层协议

应用层:

 a.域名系统DNS:

域名系统(英文:Domain Name System,缩写:DNS)是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。DNS使用UDP端口53。当前,对于每一级域名长度的限制是63个字符,域名总长度则不能超过253个字符。

  b.文件传送协议FTP:

文件传输协议(File Transfer Protocol,FTP)是用于在网络上进行文件传输的一套标准协议,它工作在 OSI 模型的第七层, TCP 模型的第四层, 即应用层, 使用 TCP 传输而不是 UDP, 客户在和服务器建立连接前要经过一个“三次握手”的过程, 保证客户与服务器之间的连接是可靠的, 而且是面向连接, 为数据传输提供可靠保证。

FTP允许用户以文件操作的方式(如文件的增、删、改、查、传送等)与另一主机相互通信。然而, 用户并不真正登录到自己想要存取的计算机上面而成为完全用户, 可用FTP程序访问远程资源, 实现用户往返传输文件、目录管理以及访问电子邮件等等, 即使双方计算机可能配有不同的操作系统和文件存储方式。

  c.简单文件传送协议TFTP:
                 TFTP是一个传输文件的简单协议,它基于UDP协议而实现,但是我们也不能确定有些TFTP协议是基于其它传输协议完成的。此协议设计的时候是进行小文件传输的。因此它不具备通常的FTP的许多功能,它只能从文件服务器上获得或写入文件,不能列出目录,不进行认证,它传输8位数据。传输中有三种模式:netascii,这是8位的ASCII码形式,另一种是octet,这是8位源数据类型;最后一种mail已经不再支持,它将返回的数据直接返回给用户而不是保存为文件。

  d.远程终端协议TELNET:

Telnet协议是TCP/IP协议族中的一员,是Internet远程登录服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用telnet程序,用它连接到服务器。终端使用者可以在telnet程序中输入命令,这些命令会在服务器上运行,就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个telnet会话,必须输入用户名和密码来登录服务器。Telnet是常用的远程控制Web服务器的方法。

Telnet远程登录服务分为以下4个过程:
                        1)本地与远程主机建立连接。该过程实际上是建立一个TCP连接,用户必须知道远程主机的Ip地址或域名;
                        2)将本地终端上输入的用户名和口令及以后输入的任何命令或字符以NVT(Net Virtual Terminal)格式传送到远程主机。该过程实际上是从本地主机向远程主机发送一个IP数据包;
                        3)将远程主机输出的NVT格式的数据转化为本地所接受的格式送回本地终端,包括输入命令回显和命令执行结果;
                        4)最后,本地终端对远程主机进行撤消连接。该过程是撤销一个TCP连接。

 e.超文本传送协议HTTP:

超文本传输协议(Hyper Text Transfer Protocol,HTTP)是一个简单的请求-响应协议,它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出;而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣,因为它使开发和部署非常地直截了当。

f.简单邮件传送协议SMTP:

SMTP是一种提供可靠且有效的电子邮件传输的协议。SMTP是建立在FTP文件传输服务上的一种邮件服务,主要用于系统之间的邮件信息传递,并提供有关来信的通知。SMTP独立于特定的传输子系统,且只需要可靠有序的数据流信道支持,SMTP的重要特性之一是其能跨越网络传输邮件,即“SMTP邮件中继”。使用SMTP,可实现相同网络处理进程之间的邮件传输,也可通过中继器或网关实现某处理进程与其他网络之间的邮件传输。

  g.邮件读取协议POP3、IMAP:

POP3,全名为“Post Office Protocol - Version 3”,即“邮局协议版本3”。是TCP/IP协议族中的一员,由RFC1939 定义。本协议主要用于支持使用客户端远程管理在服务器上的电子邮件。提供了SSL加密的POP3协议被称为POP3S。
                POP 协议支持“离线”邮件处理。其具体过程是:邮件发送到服务器上,电子邮件客户端调用邮件客户机程序以连接服务器,并下载所有未阅读的电子邮件。这种离线访问模式是一种存储转发服务,将邮件从邮件服务器端送到个人终端机器上,一般是PC机或 MAC。一旦邮件发送到 PC 机或MAC上,邮件服务器上的邮件将会被删除。但POP3邮件服务器大都可以“只下载邮件,服务器端并不删除”,也就是改进的POP3协议。

IMAP(Internet Message Access Protocol)以前称作交互邮件访问协议(Interactive Mail Access Protocol),是一个应用层协议。IMAP是斯坦福大学在1986年开发的一种邮件获取协议。它的主要作用是邮件客户端可以通过这种协议从邮件服务器上获取邮件的信息,下载邮件等。当前的权威定义是RFC3501。IMAP协议运行在TCP/IP协议之上,使用的端口是143。它与POP3协议的主要区别是用户可以不用把所有的邮件全部下载,可以通过客户端直接对服务器上的邮件进行操作。

h.动态主机配置协议DHCP:
                DHCP(动态主机配置协议)是一个局域网的网络协议。指的是由服务器控制一段IP地址范围,客户机登录服务器时就可以自动获得服务器分配的IP地址和子网掩码。默认情况下,DHCP作为Windows Server的一个服务组件不会被系统自动安装,还需要管理员手动安装并进行必要的配置。

      i.简单网络管理协议SNMP:

简单网络管理协议(SNMP) 是专门设计用于在 IP 网络管理网络节点(服务器、工作站、路由器、交换机及HUBS等)的一种标准协议,它是一种应用层协议。

        j.安全外壳协议SSH:

SSH 为 Secure Shell 的缩写,由 IETF 的网络小组(Network Working Group)所制定;SSH 为建立在应用层基础上的安全协议。SSH 是较可靠,专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序,后来又迅速扩展到其他操作平台。SSH在正确使用时可弥补网络中的漏洞。SSH客户端适用于多种平台。几乎所有UNIX平台—包括HP-UX、Linux、AIX、Solaris、Digital UNIX、Irix,以及其他平台,都可运行SSH。

从客户端来看,SSH提供两种级别的安全验证。

                        第一种级别(基于口令的安全验证)

                        第二种级别(基于密匙的安全验证)

运输层:

    a.用户数据报协议UDP

Internet 协议集支持一个无连接的传输协议,该协议称为用户数据报协议(UDP,User Datagram Protocol)。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。RFC 768   描述了 UDP。
                Internet 的传输层有两个主要协议,互为补充。无连接的是 UDP,它除了给应用程序发送数据包功能并允许它们在所需的层次上架构自己的协议之外,几乎没有做什么特别的事情。面向连接的是 TCP,该协议几乎做了所有的事情。

b.传输控制协议TCP

传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793  定义。

TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。 原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。

网络层:

        a.网际协议IP

IP是Internet Protocol(网际互连协议)的缩写,是TCP/IP体系中的网络层协议。设计IP的目的是提高网络的可扩展性:一是解决互联网问题,实现大规模、异构网络的互联互通;二是分割顶层网络应用和底层网络技术之间的耦合关系,以利于两者的独立发展。根据端到端的设计原则,IP只为主机提供一种无连接、不可靠的、尽力而为的数据包传输服务。

      b.地址解析协议ARP

地址解析协议,即ARP(Address Resolution Protocol),是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机,并接收返回消息,以此确定目标的物理地址;收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间,下次请求时直接查询ARP缓存以节约资源。地址解析协议是建立在网络中各个主机互相信任的基础上的,局域网络上的主机可以自主发送ARP应答消息,其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存;由此攻击者就可以向某一主机发送伪ARP应答报文,使其发送的信息无法到达预期的主机或到达错误的主机,这就构成了一个ARP欺骗。ARP命令可用于查询本机ARP缓存中IP地址和MAC地址的对应关系、添加或删除静态对应关系等。相关协议有RARP、代理ARP。NDP用于在IPv6中代替地址解析协议。

  c.逆地址解析额协议RARP

反向地址转换协议(RARP:Reverse Address Resolution Protocol) 允许局域网的物理机器从网关服务器的 ARP 表或者缓存上请求其 IP 地址。网络管理员在局域网网关路由器里创建一个表以映射物理地址(MAC)和与其对应的 IP 地址。当设置一台新的机器时,其 RARP 客户机程序需要向路由器上的 RARP 服务器请求相应的 IP 地址。假设在路由表中已经设置了一个记录,RARP 服务器将会返回 IP 地址给机器,此机器就会存储起来以便日后使用。 RARP 可以使用于以太网、光纤分布式数据接口及令牌环 LAN

d.网际控制报文协议ICMP

ICMP(Internet Control Message Protocol)Internet控制报文协议。它是TCP/IP协议簇的一个子协议,用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用。 
                ICMP使用IP的基本支持,就像它是一个更高级别的协议,但是,ICMP实际上是IP的一个组成部分,必须由每个IP模块实现。

e.网际组管理协议IGMP

Internet 组管理协议称为IGMP协议(Internet Group Management Protocol),是因特网协议家族中的一个组播协议。该协议运行在主机和组播路由器之间。IGMP协议共有三个版本,即IGMPv1、v2 和v3。

    f.内部网关协议RIP

路由信息协议RIP(Routing Information Protocol)是基于距离矢量算法的路由协议,利用跳数来作为计量标准

    g.内部网关协议OSPF

OSPF(Open Shortest Path First开放式最短路径优先)是一个内部网关协议(Interior Gateway Protocol,简称IGP),用于在单一自治系统(autonomous system,AS)内决策路由。是对链路状态路由协议的一种实现,隶属内部网关协议(IGP),故运作于自治系统内部。著名的迪克斯彻(Dijkstra)算法被用来计算最短路径树。OSPF支持负载均衡和基于服务类型的选路,也支持多种路由形式,如特定主机路由和子网路由等。

      h.外部网关协议BGP

边界网关协议(BGP)是运行于 TCP 上的一种自治系统的路由协议。 BGP 是唯一一个用来处理像因特网大小的网络的协议,也是唯一能够妥善处理好不相关路由域间的多路连接的协议。 BGP 构建在 EGP 的经验之上。 BGP 系统的主要功能是和其他的 BGP 系统交换网络可达信息。网络可达信息包括列出的自治系统(AS)的信息。这些信息有效地构造了 AS 互联的拓扑图并由此清除了路由环路,同时在 AS 级别上可实施策略决策。

    i.虚拟专用网VPN

虚拟专用网络(VPN)的功能是:在公用网络上建立专用网络,进行加密通讯。在企业网络中有广泛应用。VPN网关通过对数据包的加密和数据包目标地址的转换实现远程访问。VPN可通过服务器、硬件、软件等多种方式实现。

    j.网络地址转换NAT

                使用端口号的NAT也叫做网络地址与端口号转换NAPT。

k.多协议标记交换MPLS

多协议标签交换(英语:Multi-Protocol Label Switching,缩写为MPLS)是一种在开放的通信网上利用标签引导数据高速、高效传输的新技术。多协议的含义是指MPLS不但可以支持多种网络层层面上的协议,还可以兼容第二层的多种数据链路层技术。

     l.路由器

数据链路层:

      a.自动请求重传ARQ

自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层的错误纠正协议之一。它包括停止等待ARQ协议和连续ARQ协议,错误侦测(Error Detection)、正面确认(Positive Acknowledgment)、逾时重传(Retransmission after Timeout)与负面确认继以重传(Negative Acknowledgment and Retransmission)等机制。

b.点对点协议PPP

点对点协议(Point to Point Protocol,PPP)为在点对点连接上传输多协议数据包提供了一个标准方法。PPP 最初设计是为两个对等节点之间的 IP 流量传输提供一种封装协议。在 TCP-IP 协议集中它是一种用来同步调制连接的数据链路层协议(OSI模式中的第二层),替代了原来非标准的第二层协议,即 SLIP。除了 IP 以外 PPP 还可以携带其它协议,包括 DECnet 和 Novell 的 Internet 网包交换(IPX)。

点到点协议(Point to Point Protocol,PPP)是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。 [1]  这种链路提供全双工操作,并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据,使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。PPP具有以下功能:
                        (1)PPP具有动态分配IP地址的能力,允许在连接时刻协商IP地址;
                        (2)PPP支持多种网络协议,比如TCP/IP、NetBEUI、NWLINK等;
                        (3)PPP具有错误检测能力,但不具备纠错能力,所以ppp是不可靠传输协议;
                        (4)无重传的机制,网络开销小,速度快。
                        (5)PPP具有身份验证功能。
                        (6) PPP可以用于多种类型的物理介质上,包括串口线、电话线、移动电话和光纤(例如SDH),PPP也用于Internet接入。

        部分组成

封装:一种封装多协议数据报的方法。PPP 封装提供了不同网络层协议同时在同一链路传输的多路复用技术。PPP 封装精心设计,能保持对大多数常用硬件的兼容性,克服了SLIP不足之处的一种多用途、点到点协议,它提供的WAN数据链接封装服务类似于LAN所提供的封闭服务。所以,PPP不仅仅提供帧定界,而且提供协议标识和位级完整性检查服务。

链路控制协议(LCP):一种扩展链路控制协议,用于建立、配置、测试和管理数据链路连接。

网络控制协议(NCP):协商该链路上所传输的数据包格式与类型,建立、配置不同的网络层协议;

配置:使用链路控制协议的简单和自制机制。该机制也应用于其它控制协议,例如:网络控制协议(NCP)

        c.CSMA/CD

CSMA/CD即载波侦听多路访问/冲突检测,是广播型信道中采用一种随机访问技术的竞争型访问方法,具有多目标地址的特点。它处于一种总线型局域网结构,其物理拓扑结构正逐步向星型发展。CSMA/CD采用分布式控制方法,所有结点之间不存在控制与被控制的关系。

载波监听多点接入/碰撞检测

根据以上所讨论的,可以把CSMA/CD协议的要点归纳如下:

(1)准备发送:适配器从网络层获得一个分组,加上以太网的首部和尾部,组成以太网帧,放入适配器的缓存中。但在发送之前,必须先检测信道。

(2)检测信道:若检测到信道忙,则应不停地检测,一直等待信道转为空闲。若检测到信道空闲,并在96比特时间内信道保持空闲(保证了帧间最小间隔),就发送这个帧。

(3)在发送过程中仍不停地检测信道,即网络适配器要边发送边监听。这里只有两种可能性:

一是发送成功:在争用期内一直未检测到碰撞。这个帧肯定能够发送成功。发送完毕后,其他什么也不做。然后回到(1)。

二是发送失败:在争用期内检测到碰撞。这时立即停止发送数据,并按规定发送人为干扰信号。适配器接着就执行指数退避算法,等待r倍512比特时间后,返回到步骤(2),继续检测信道。但若重传达16次仍不能成功,则停止重传而向上报错。

以太网每发送完一帧,一定要把已发送的帧暂时保留一下。如果在争用期内检测出发生了碰撞,那么还要在推迟一段时间后再把这个暂时保留的帧重传一次。

d.网桥

  e.交换机

物理层:

    a.中继器

       b.集线器

其他:

二、TCP和UDP的区别

(1)UDP协议概述

        UDP协议特点
(1)UDP是无连接的传输层协议;
(2)UDP使用尽最大努力交付,不保证可靠交付;
(3)UDP是面向报文的,对应用层交下来的报文,不合并,不拆分,保留原报文的边界;
(4)UDP没有拥塞控制,因此即使网络出现拥塞也不会降低发送速率;
(5)UDP支持一对一 一对多 多对多的交互通信;
(6)UDP的首部开销小,只有8字节.
(2)TCP概述
        TCP协议的主要特点
(1TCP是面向连接的运输层协议;所谓面向连接就是双方传输数据之前,必须先建立一条通道,例如三次握⼿就是建议通道的⼀个过程,而四次挥手则是结束销毁通道的⼀个其中过程。
(2)每一条TCP连接只能有两个端点(即两个套接字),只能是点对点的;
(3TCP提供可靠的传输服务。传送的数据无差错、不丢失、不重复、按序到达;
(4TCP提供全双工通信。允许通信双方的应用进程在任何时候都可以发送数据,因为两端都设有发送缓存和接收缓存;
(5)面向字节流。虽然应用程序与TCP交互是一次一个大小不等的数据块,但TCP把这些数据看成⼀连串无结构的字节流,它不保证接收方收到的数据块和发送方发送的数据块具有对应大小关系,例如,发送方应用程序交给发送方的TCP10个数据块,但接收方的TCP可能只收到了4个数据块就把收到的字节流交付给上层的应用程序,但字节流完全⼀样。

(3)概述区别

UDP 在传送数据之前不需要先建立连接,远地主机在收到 UDP 报文后,不需要给出任何确认。
虽然 UDP 不提供可靠交付,但在某些情况下 UDP 确是一种最有效的工作方式(一般用于即时通信),比如: QQ 语音、 QQ 视频 、直播等等。
TCP 提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP 不提供⼴播或多播服务。由于 TCP 要提供可靠的,,面向连接的传输服务(TCP的可靠体现在TCP在传递数据之前,会有三次握⼿来建⽴连接,而且在数据传递时,有确认、窗⼝、重传、拥塞控制机制,在数据传完后,还会断开连接以来节约系统资源),这些难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。TCP ⼀般用于文件传输、发送和接收邮件、远程登录等场景。
(4)TCP和UDP区别
        TCP和UDP的区别
(1)TCP是可靠传输,UDP是不可靠传输;
(2)TCP面向连接,UDP无连接;
(3)TCP传输数据有序,UDP不保证数据的有序性;
(4)TCP不保存数据边界,UDP保留数据边界;
(5)TCP传输速度相对UDP较慢;
(6)TCP有流量控制和拥塞控制,UDP没有;
(7)TCP是重量级协议,UDP是轻量级协议;
(8)TCP首部较长20字节,UDP首部较短8字节;

 
(5)基于TCP和UDP的上层协议
        基于TCPUDP的常用协议
HTTP、HTTPSFTPTELNETSMTP(简单邮件传输协议)协议基于可靠的TCP协议。TFTPDNSDHCP
TFTP、SNMP(简单⽹络管理协议)RIP基于不可靠的UDP协议

        TCP应用场景: 
                效率要求相对低,但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作,相比之下效没有UDP高。几个例子:文件传输(准确高要求高、但是速度可以相对慢)、接受邮件、 远程登录。

  UDP应用场景:
                效率要求相对高,对准确性要求相对低的场景。几个例子: QQ聊天、在线视频、网络语音电话(即时通讯,速度要求高,但是出现偶尔断续不是太大问题,粗此处完全可以使用重发机制)、广播通信(广播、多播)        

        TCP 对应的应用层协议

FTP:定义了文件传输协议,使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件,上传主页,都要用到 FTP 服务。

Telnet:它是一种用于远程登陆的端口,用户可以以自己的身份远程连接到计算机上,通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是-纯字符界面的,支持 BBS 的服务器将 23 端口打开,对外提供服务。

SMTP:定义了简单邮件传送协议,现在很多邮件服务器都用的是这个协议,用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口,所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏,服务器开放的是 25 号端口。

POP3:它是和 SMTP 对应,POP3 用于接收邮件。通常情况下,POP3 协议所用的是 110 端口。也是说,只要你有相应的使用 POP3 协议的程序(例如 Fo-xmail 或 Outlook),就可以不以 Web 方式登陆进邮箱界面,直接用邮件程序就可以收到邮件(如是163 邮箱就没有必要先进入网易网站,再进入自己的邮-箱来收信)。

HTTP:从 Web 服务器传输超文本到本地浏览器的传送协议。

        UDP 对应的应用层协议

DNS:用于域名解析服务,将域名地址转换为 IP 地址。DNS 用的是 53 号端口。

SNMP:简单网络管理协议,使用 161 号端口,是用来管理网络设备的。由于网络设备很多,无连接的服务就体现出其优势。

TFTP(Trival File Transfer Protocal):简单文件传输协议,该协议在熟知端口 69 上使用 UDP 服务。

三、TCP可靠传输的原理:序列号与确认号、重传机制、流量控制、拥塞控制、首部检验和

(1)应用数据被分割成 TCP 认为最适合发送的数据块

(2)序列号与确认号:TCP是面向字节流的,在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则指本报文段所发送的数据的第一个字节的序号。确认号:是期望收到对方下一个报文段的第一个数据字节的序号。TCP对收到的每一个报文进行确认。

(3)重传机制:发送窗口=min(拥塞窗口,接收窗口)。停止等待协议、连续ARQ协议。两种重传情况:超时重传、冗余ACK重传

(4)流量控制:利用滑动窗口实现流量控制。实时调整发送窗口的大小。TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的实践到期,就发送一个零窗口探测报文(仅携带1字节数据)。即使设置零窗口,也必须接收零窗口探测报文段、确认报文段、携带紧急数据的报文段、

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

(5)拥塞控制:TCP控制拥塞的方法:慢开始、拥塞避免、快重传、快恢复

(6)首部检验和:

检验和字段检验的范围包括首部和数据两部分。计算检验和时,要在TCP报文段前面加上12字节的伪首部。检验和出错则丢且该报文段。

四、TCP三次握手,四次挥手过程

(1)三次握手和四次挥手

(2)三次握手

1、第⼀次握⼿:客户端给服务器发送⼀个 SYN 报文。
2、第⼆次握⼿:服务器收到 SYN 报⽂之后,会应答⼀个 SYN+ACK 报文。
3、第三次握⼿:客户端收到 SYN+ACK 报⽂之后,会回应⼀个 ACK 报文。
4、服务器收到 ACK 报文之后,三次握⼿建⽴完成。
作用是为了确认双方的接收与发送能力是否正常。
这里我顺便解释⼀下为啥只有三次握⼿才能确认双方的接受与发送能力是否正常,而两次却不可以:
第⼀次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
第⼆次握⼿:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握⼿:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能⼒正常,服务器自己的发送、接收能力也正常。
因此,需要三次握手才能确认双方的接收与发送能力是否正常。
这样回答其实也是可以的,但我觉得,这个过程的我们应该要描述的更详细⼀点,因为三次握手的过程中,双方是由很多状态的改变的,而这些状态,也是面试官可能会问的点。所以我觉得在回答三次握⼿的时候,我们应该要描述的详细⼀点,而且描述的详细⼀点意味着可以扯久⼀点。加分的描述我觉得应该是这样:
        刚开始客户端处于 closed 的状态,服务端处于 listen 状态。然后
1、第⼀次握手:客户端给服务端发⼀个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于SYN_Send 状态。
2、第⼆次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s),同时会把客户端的 ISN + 1 作为 ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_REVD 的状态。
3、第三次握⼿:客户端收到 SYN 报文之后,会发送⼀个 ACK 报⽂,当然,也是⼀样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报⽂,此时客户端处于establised 状态。
4、服务器收到 ACK 报文之后,也处于 establised 状态,此时,双方以建立起了链接
        三次握手的作用
1、确认双方的接受能力、发送能力是否正常。
2、指定自己的初始化序列号,为后面的可靠传送做准备。
                1、(ISN)是固定的吗
三次握⼿的⼀个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的 时候如何按序列号组装数据。 如果ISN是固定的,攻击者很容易猜出后续的确认号,因此 ISN 是动态生成的。
                2、什么是半连接队列
服务器第⼀次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在⼀个队列里,我们把这种队列称之为半连接队列。当然还有⼀个全连接队列,就是已经完成三次握⼿,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
3、SYN-ACK重传次数
这里再补充⼀点关于SYN-ACK 重传次数的问题: 服务器发送完SYN-ACK包,如果未收到客户确认包,服 务器进行首次重传,等待⼀段时间仍未收到客户确认包,进⾏第⼆次重传,如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不⼀定相同,⼀般会是指数增⻓,例如间隔时间为 1s, 2s, 4s, 8s,
                4、三次握⼿过程中可以携带数据吗
很多⼈可能会认为三次握⼿都不能携带数据,其实第三次握⼿的时候,是可以携带数据的。也就是说,第⼀次、第⼆次握手不可以携带数据,而第三次握⼿是可以携带数据的。
为什么这样呢?大家可以想⼀个问题,假如第⼀次握⼿可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第⼀次握⼿中的 SYN 报文中放入大量的数据,因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发 SYN 报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。
也就是说,第⼀次握⼿可以放数据的话,其中⼀个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话,此时客户端已经处于 established 状态,也就是说,对于客户端来说,他已经建立起连接了, 并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没啥毛病。

5、为什么需要三次握手,而不是两次:

①TCP提供全双工通信,保证客户端和服务器的首发都正常

②防止已失效的连接请求报文段突然又传送到了服务端。若采用两次握手,失效的报文段到达服务端时,服务端发送ACK则连接建立,对于客户来说并没有建立连接,浪费资源。

(3)四次挥手

四次挥手也⼀样,千万不要对方⼀个 FIN 报文,我方⼀个 ACK 报文,再我方⼀个 FIN 报文,我方⼀个 ACK 报文。
刚开始双⽅都处于 establised 状态,假如是客户端先发起关闭请求,则:
1、第⼀次挥手:客户端发送⼀个 FIN 报⽂,报⽂中会指定⼀个序列号。此时客户端处于FIN-WAIT-1状态。
2、第⼆次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。客户端收到此报文后处于FIN-WAIT-2状态
3、第三次挥手:如果服务端也想断开连接了,和客户端的第⼀次挥手⼀样,发给 FIN 报⽂,且指定⼀个序列号。 此时服务端处于 LAST_ACK 的状态。
4、第四次挥手:客户端收到 FIN 之后,⼀样发送⼀个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己ACK 报⽂的序列号值,此时客户端处于 TIME_WAIT 状态。需要过⼀阵子以确保服务端收到自己的 ACK 报文之后才会进⼊ CLOSED 状态,经过时间等到计时器设置的时间2MSL后,进入到CLOSED状态
5、服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态
状态:
LISTEN - 侦听来自远方TCP端口的连接请求;
SYN-SENT -在发送连接请求后等待匹配的连接请求;
SYN-RECEIVED - 在收到和发送⼀个连接请求后等待对连接请求的确认;
ESTABLISHED- 代表⼀个打开的连接,数据可以传送给⽤户;
FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;
FIN-WAIT-2 - 从远程TCP等待连接中断请求;
CLOSE-WAIT -等待应用程序关闭服务端到客户端的连接(等待从本地用户发来的连接中断请求);
CLOSING -等待远程TCP对连接中断的确认;
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认;
TIME-WAIT -等足⾜够的时间以确保远程TCP接收到连接中断请求的确认;
CLOSED - 没有任何连接状态;
MSL-最长报文段寿命,建议2min
为什么客户在TIME-WAIT状态必须等待2MSL
1、为了保证 A 发送的最后⼀个 ACK 报⽂段能够到达 B。这个 ACK 报⽂段有可能丢失,因⽽使处在 LAST-ACK 状 态的 B 收不到对已发送的 FIN + ACK 报⽂段的确认。B 会超时重传这个 FIN+ACK 报⽂段,⽽ A 就能在 2MSL 时间 内(超时 + 1MSL 传输)收到这个重传的 FIN+ACK 报⽂段。接着 A 重传⼀次确认,重新启动 2MSL 计时器。最后,A B 都正常进入到 CLOSED 状态。如果 A TIME-WAIT 状态不等待⼀段时间,⽽是在发送完 ACK 报⽂段后立即释放连接,那么就无法收到B重传的 FIN + ACK 报⽂段,因而也不会再发送⼀次确认报文段,这样,B 就无法按照正常步骤进⼊ CLOSED 状态。
2、 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后⼀个 ACK 报⽂段后,再经过时间 2MSL,就可以使本连接持续的时间内所产⽣的所有报⽂段都从网络中消失。这样就可以使下⼀个连接中不会出现这种旧的连接请求报文段。

①为了保证发送的最后一个ACK能到达服务端
②防止已失效的连接请求报文段出现在本连接中
(4)保活计时器
TCP设有一个保活计时器,服务器每收到一次客户机的数据,就重新设置保活计时器,时间的设置通常是两小时。若两小时没有收到客户的数据,服务器就发送一个探测报文段,以后则每间隔75秒发送一次。若一连发送10个探测报文段后仍无客户的响应,服务器就认为客户端出现了故障,则关闭这个连接
除时间等待计时器外,TCP 还有⼀个保活计时器(keepalive timer)。设想这样的场景:客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发⽣故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到⼀次客户的数据,就重新设置保活计时器,时间的设置通常是两个小时。若两个小时都没有收到客户端的数据,服务端就发送⼀个探测报⽂段,以后则每隔 75 秒钟发送⼀次。若连续发送 10个 探测报⽂段后仍然无客户端的响应,服务端就认为客户端出了故障,接着就关闭这个连接。

五、timewait 和 closewait

CLOSE-WAIT - 等待应用程序关闭服务端到客户端的连接
TIME-WAIT -等待⾜够的时间以确保远程TCP接收到连接中断请求的确认;
1) 主动关闭连接的一方,调用close();协议层发送FIN包 ;
        2) 被动关闭的一方收到FIN包后,协议层回复ACK;然后被动关闭的一方,进入CLOSE_WAIT状态,主动关闭的一方等待对方关闭,则进入FIN_WAIT_2状态;此时,主动关闭的一方等待被动关闭一方的应用程序,调用close操作 ;
        3) 被动关闭的一方在完成所有数据发送后,调用close()操作;此时,协议层发送FIN包给主动关闭的一方,等待对方的ACK,被动关闭的一方进入LAST_ACK状态;
        4) 主动关闭的一方收到FIN包,协议层回复ACK;此时,主动关闭连接的一方,进入TIME_WAIT状态;而被动关闭的一方,进入CLOSED状态 ;
        5) 等待2MSL时间,主动关闭的一方,结束TIME_WAIT,进入CLOSED状态 ;
我们考虑高并发短连接的业务场景,在高并发短连接的 TCP 服务器上,当服务器处理完请求后主动请求关闭连接,这样服务器上会有大量的连接处于 TIME_WAIT 状态,服务器维护每一个连接需要一个 socket,也就是每个连接会占用一个文件描述符,而文件描述符的使用是有上限的,如果持续高并发,会导致一些正常的 连接失败。

解决方案:修改配置或设置 SO_REUSEADDR 套接字,使得服务器处于 TIME-WAIT 状态下的端口能够快速回收和重用。

服务器可以设置 SO_REUSEADDR 套接字选项来通知内核,如果端口被占用,但 TCP 连接位于 TIME_WAIT 状态时可以重用端口。如果你的服务器程序停止后想立即重启,而新的套接字依旧希望使用同一端口,此时 SO_REUSEADDR 选项就可以避免 TIME-WAIT 状态。
也可以采用长连接的方式减少 TCP 的连接与断开,在长连接的业务中往往不需要考虑 TIME-WAIT 状态,但其实在长连接的业务中并发量一般不会太高。

六、HTTP:报文格式、1.0 1.1 2.0、状态码,无状态解决(Cookie,Session)

(1)HTTP概念

HTTP 协议一般指 HTTP(超文本传输协议)。

超文本传输协议(英语:HyperText Transfer Protocol,缩写:HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议,是因特网上应用最为广泛的一种网络传输协议,所有的 WWW 文件都必须遵守这个标准。

HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。

HTTP是面向事务的应用层协议。

(2)HTTP工作原理

HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

Web服务器有:Apache服务器,IIS服务器(Internet Information Services)等。

Web服务器根据接收到的请求后,向客户端发送响应信息。

HTTP默认端口号为80,但是你也可以改为8080或者其他端口。

HTTP三点注意事项:

  • HTTP是无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
  • HTTP是媒体独立的:这意味着,只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
  • HTTP是无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。

HTTP协议通信流程:

(3) HTTP消息结构

HTTP是基于客户端/服务端(C/S)的架构模型,通过一个可靠的链接来交换信息,是一个无状态的请求/响应协议。

一个HTTP"客户端"是一个应用程序(Web浏览器或其他任何客户端),通过连接到服务器达到向服务器发送一个或多个HTTP的请求的目的。

一个HTTP"服务器"同样也是一个应用程序(通常是一个Web服务,如Apache Web服务器或IIS服务器等),通过接收客户端的请求并向客户端发送HTTP响应数据。

HTTP使用统一资源标识符(Uniform Resource Identifiers, URI)来传输数据和建立连接。

一旦建立连接后,数据消息就通过类似Internet邮件所使用的格式[RFC5322]和多用途Internet邮件扩展(MIME)[RFC2045]来传送。

客户端请求消息

客户端发送一个HTTP请求到服务器的请求消息包括以下格式:请求行(request line)、请求头部(header)、空行和请求数据四个部分组成,下图给出了请求报文的一般格式。

服务器响应消息

HTTP响应也由四个部分组成,分别是:状态行、消息报头、空行和响应正文。

实例:

下面实例是一点典型的使用GET来传递数据的实例:

客户端请求:

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

服务端响应:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

输出结果:

Hello World! My payload includes a trailing CRLF.

(4)HTTP请求类型

根据 HTTP 标准,HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD 方法。

HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序号 方法 描述
1 GET 请求指定的页面信息,并返回实体主体。
2 HEAD 类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头
3 POST 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
5 DELETE 请求服务器删除指定的页面。
6 CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7 OPTIONS 允许客户端查看服务器的性能。
8 TRACE 回显服务器收到的请求,主要用于测试或诊断。
9 PATCH 是对 PUT 方法的补充,用来对已知资源进行局部更新 。

(5)HTTP 响应头信息

应答头 说明
Allow

服务器支持哪些请求方法(如GET、POST等)。

Content-Encoding

文档的编码(Encode)方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩,但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此,Servlet应该通过查看Accept-Encoding头(即request.getHeader("Accept-Encoding"))检查浏览器是否支持gzip,为支持gzip的浏览器返回经gzip压缩的HTML页面,为其他浏览器返回普通页面。

Content-Length

表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势,可以把输出文档写入 ByteArrayOutputStream,完成后查看其大小,然后把该值放入Content-Length头,最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。

Content-Type

表示后面的文档属于什么MIME类型。Servlet默认为text/plain,但通常需要显式地指定为text/html。由于经常要设置Content-Type,因此HttpServletResponse提供了一个专用的方法setContentType。

Date

当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。

Expires

应该在什么时候认为文档已经过期,从而不再缓存它?

Last-Modified

文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期,该请求将被视为一个条件GET,只有改动时间迟于指定时间的文档才会返回,否则返回一个304(Not Modified)状态。Last-Modified也可用setDateHeader方法来设置。

Location

表示客户应当到哪里去提取文档。Location通常不是直接设置的,而是通过HttpServletResponse的sendRedirect方法,该方法同时设置状态代码为302。

Refresh

表示浏览器应该在多少时间之后刷新文档,以秒计。除了刷新当前文档之外,你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。 
注意这种功能通常是通过设置HTML页面HEAD区的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">实现,这是因为,自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是,对于Servlet来说,直接设置Refresh头更加方便。

注意Refresh的意义是"N秒之后刷新本页面或访问指定页面",而不是"每隔N秒刷新本页面或访问指定页面"。因此,连续刷新要求每次都发送一个Refresh头,而发送204状态代码则可以阻止浏览器继续刷新,不管是使用Refresh头还是<META HTTP-EQUIV="Refresh" ...>。

注意Refresh头不属于HTTP 1.1正式规范的一部分,而是一个扩展,但Netscape和IE都支持它。

Server

服务器名字。Servlet一般不设置这个值,而是由Web服务器自己设置。

Set-Cookie

设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...),而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。

WWW-Authenticate

客户应该在Authorization头中提供什么类型的授权信息?在包含401(Unauthorized)状态行的应答中这个头是必需的。例如,response.setHeader("WWW-Authenticate", "BASIC realm=\"executives\"")。 
注意Servlet一般不进行这方面的处理,而是让Web服务器的专门机制来控制受密码保护页面的访问(例如.htaccess)。

(6)HTTP状态码

当浏览者访问一个网页时,浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前,此网页所在的服务器会返回一个包含 HTTP 状态码的信息头(server header)用以响应浏览器的请求。

HTTP 状态码的英文为 HTTP Status Code。。

下面是常见的 HTTP 状态码:

  • 200 - 请求成功
  • 301 - 资源(网页等)被永久转移到其它URL
  • 404 - 请求的资源(网页等)不存在
  • 500 - 内部服务器错误

HTTP 状态码分类

HTTP 状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型。响应分为五类:信息响应(100–199),成功响应(200–299),重定向(300–399),客户端错误(400–499)和服务器错误 (500–599):

分类 分类描述
1** 信息,服务器收到请求,需要请求者继续执行操作
2** 成功,操作被成功接收并处理
3** 重定向,需要进一步的操作以完成请求
4** 客户端错误,请求包含语法错误或无法完成请求
5** 服务器错误,服务器在处理请求的过程中发生了错误
状态码分类
1xx:表示目前是协议的中间状态,还需要后续请求
2xx:表示请求成功
3xx:表示重定向状态,需要重新请求
4xx:表示请求报文错误
5xx:服务器端错误
常⽤状态码
101 切换请求协议,从 HTTP 切换到 WebSocket
200 请求成功,有响应体
301 永久重定向:会缓存
302 临时重定向:不会缓存
304 协商缓存命中
403 服务器禁止访问
404 资源未找到
400 请求错误
500 服务器端错误
503 服务器繁忙

(7)HTTP content-type

Content-Type(内容类型),一般是指网页中存在的 Content-Type,用于定义网络文件的类型和网页的编码,决定浏览器将以什么形式、什么编码读取这个文件,这就是经常看到一些 PHP 网页点击的结果却是下载一个文件或一张图片的原因。

Content-Type 标头告诉客户端实际返回的内容的内容类型。

语法格式:

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

(8)get与post区别

        

GET POST
后退按钮/刷新 无害 数据会被重新提交(浏览器应该告知用户数据会被重新提交)。
书签 可收藏为书签 不可收藏为书签
缓存 能被缓存 不能缓存
编码类型 application/x-www-form-urlencoded application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史 参数保留在浏览器历史中。 参数不会保存在浏览器历史中。
对数据长度的限制 是的。当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。 无限制。
对数据类型的限制 只允许 ASCII 字符。 没有限制。也允许二进制数据。
安全性

与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。

在发送密码或其他敏感信息时绝不要使用 GET !

POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性 数据在 URL 中对所有人都是可见的。 数据不会显示在 URL 中。
        a.使用场景
GET 用于获取资源,而POST 用于传输实体主体。
当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。
        b.参数
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而POST 的参数存储 在实体主体中。不能因为 POST 参数存储在实体主体中就认为它的安全性更⾼,因为照样可以通过⼀些抓包⼯具 (Fiddler)查看。 因为 URL 只⽀持 ASCII 码,因此 GET 的参数中如果存在中⽂等字符就需要先进⾏编码。例如 “中文” 会转换为%E4%B8%AD%E6%96%87 ,而空格会转换为 %20 POST 参数⽀持标准字符集。
        c.安全性
安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。
GET 方法是安全的,而POST 却不是,因为 POST 的目的是传送实体主体内容,这个内容可能是用户上传的表单数 据,上传成功之后,服务器可能把这个数据存储到数据库中,因此状态也就发生了改变。
GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied安全的⽅法除了 GET 之外还有:HEADOPTIONS
不安全的⽅法除了 POST 之外还有 PUTDELETE
        d.幂等性
幂等的 HTTP ⽅法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是⼀样的。换句话说就是,幂等方法不应该具有副作用(统计用途除外)。
所有的安全方法也都是幂等的。
在正确实现的条件下,GETHEADPUT DELETE 等⽅法都是幂等的,而POST ⽅法不是。
GET /pageX HTTP/1.1 是幂等的,连续调⽤多次,客户端接收到的结果都是⼀样的:
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1Copy to clipboardErrorCopied
POST /add_row HTTP/1.1 不是幂等的,如果调⽤多次,就会增加多⾏记录:
POST /add_row HTTP/1.1 -> Adds a 1nd row
POST /add_row HTTP/1.1 -> Adds a 2nd row
POST /add_row HTTP/1.1 -> Adds a 3rd rowCopy to clipboardErrorCopied
DELETE /idX/delete HTTP/1.1 是幂等的,即使不同的请求接收到的状态码不⼀样:
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1 -> Returns 404Copy to clipboardErrorCopied
        e.可缓存
如果要对响应进行缓存,需要满足以下条件:
请求报文的 HTTP 方法本身是可缓存的,包括 GET HEAD,但是 PUT DELETE 不可缓存,POST 在多数 情况下不可缓存的。
响应报⽂的状态码是可缓存的,包括:200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
响应报⽂的 Cache-Control 首部字段没有指定不进行缓存。
        f.XMLHttpRequest
为了阐述 POST GET 的另⼀个区别,需要先了解 XMLHttpRequest
XMLHttpRequest 是⼀个 API,它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了⼀个通过 URL 来获取数据的简单⽅式,并且不会使整个⻚⾯刷新。这使得⽹⻚只更新⼀部分⻚⾯⽽不会打扰到⽤
户。XMLHttpRequest AJAX 中被⼤量使⽤。
在使⽤ XMLHttpRequest POST ⽅法时,浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这 么做,例如火狐就不会。而GET 方 Header Data 会⼀起发送。

(9)各协议与http之间的关系:

(10)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操作,就建立一次连接。
持续连接(长连接):服务器在发送响应后仍然在一段时间内保持这条连接,使同一个客户和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。
持续连接有两种方式:非流水线方式和流水线方式。非流水线方式:客户在收到前一个响应之后才能发送下一个请求。流水线方式:客户在收到响应之前就可以发送新的请求报文,但是服务器必须按照顺序处理这些请求报文。
        HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。

(11)HTTP是不保存状态的协议,如何保存用户状态?

HTTP是无状态的,如何保存用户状态。

HTTP 是⼀种不保存状态,即⽆状态(stateless)协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢?
Session 机制的存在就是为了解决这个问题,Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了(⼀般情况下,服务器会在⼀定时间内保存这个 Session,过了时间限制,就会销毁这个Session)。 在服务端保存 Session 的方法很多,最常用的就是内存和数据库(比如是使用内存数据库redis保 存)。既然 Session 存放在服务器端,那么我们如何实现 Session 跟踪呢?大部分情况下,我们都是通过在 Cookie 中附加⼀个 Session ID 来⽅式来跟踪。
        Cookie 被禁⽤怎么办?
最常用的就是利⽤ URL 重写把 Session ID 直接附加在URL路径的后⾯。

(12)Cookie的作用是什么?Session有什么区别?

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式,但是两者的应用场景不太⼀样。
        Cookie ⼀般用来保存用户信息 比如
①我们在 Cookie 中保存已经登录过得用户信息,下次访问网站的时候页面可以自动帮你登录的⼀些基本信息给填了;
②⼀般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了,这是因为用户登录的时候我们可以存放了⼀个Token Cookie 中,下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑,重新 登录⼀般要将 Token 重写)
③登录⼀次网站后访问网站其他⻚⾯不需要重新登录。
        Session 的 主要作用就是通过服务端记录用户的状态。 典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
Cookie 数据保存在客户端(浏览器端)Session 数据保存在服务器端。
Cookie 存储在客户端中,而Session存储在服务器上,相对来说 Session 安全性更⾼。如果要在Cookie 中存储⼀些敏感信息,不要直接写入Cookie 中,最好能将 Cookie 信息加密然后使用到 的时候再去服务器端解密。
(13)HTTP 1.0HTTP 1.1的主要区别是什么?
HTTP1.0最早在网页中使用是在1996年,那个时候只是使用⼀些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始⼴泛应⽤于现在的各⼤浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:
1. 长连接: HTTP/1.0中,默认使用的是短连接,也就是说每次请求都要重新建立一次连接。 HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销,如果每次请求都要这样的话,开销会比较大。因此最好能维持一个长连接,可以用一个长连接来发多个请求。HTTP 1.1起,默认使用长连接 ,默认开启Connection keep-alive HTTP/1.1 的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前⼀个响应后才能发 送下⼀个请求。
2. 错误状态响应码 :HTTP1.1中新增了24个错误状态响应码,如409Conflict)表示请求的
资源与资源的当前状态发⽣冲突;410Gone)表示服务器上的某个资源被永久性的删除。
3. 缓存处理 :HTTP1.0中主要使⽤header⾥的If-Modified-Since,Expires来做为缓存判断的标 准,HTTP1.1则引⼊了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用:HTTP1.0中,存在⼀些浪费带宽的现象,例如客户端只是需要某个对象的⼀部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引⼊了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就⽅便了开发者⾃由的选择以便于充分利用带宽和连接。
其他:
http1.0:不能长连接,只能短连接
http1.1:可以长连接,也就是说,一个TCP连接可以发送多个HTTP请求,不过服务器只能按照顺序一个一个响应。不过规定了用Pipelining来试图解决这个问题,不过该功能默认是关闭的。Pipelining的意思就是说,可以在⼀个连接中发送多个请求(不需要等待响应),不过服务器端必须要按照收到的顺序默认情况下浏览器不开启该功能。
http2.0:采用了多路复用,它把HTTP报文分解成更小的⼆进制帧来传送,不同的HTTP请求报文可以混合在⼀个TCP连接上传输,服务器收到后,在根据⼆进制帧里面存放的ID来进行分类,拼接。采用这种方式,相当于服务器可以同时处理几个不同的HTTP请求,也就是说,不需要吧整个HTTP请求处理完,就可以去处理其他的HTTP请求了。
并且HTTP还对请求头部进⾏了压缩

附加:

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别?

  • HTTP/1.* 一次请求-响应,建立一个连接,用完关闭;每一个请求都要建立一个连接;

  • HTTP/1.1 Pipeling解决方式为,若干个请求排队串行化单线程处理,后面的请求等待前面请求的返回才能获得执行机会,一旦有某请求超时等,后续请求只能被阻塞,毫无办法,也就是人们常说的线头阻塞;

  • HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重,不会影响到其它连接的正常执行;

(14)URIURL的区别是什么

URI(Uniform Resource Identifier) 是统一资源标志符,可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符,可以提供该资源的路径。它是一种具
体的 URI,即 URL 可以用来标识一个资源,而且还指明了如何 locate 这个资源。
URI的作用像身份证号一样,URL的作用更像家庭住址一样。URL是一种具体的URI,它不仅唯一标识资源,而且还提供了定位该资源的信息。

(15)HTTP 如何实现长连接?在什么时候会超时?

通过在头部(请求和响应头)设置 Connection: keep-aliveHTTP1.0协议支持,但是默认关闭,从HTTP1.1协议以后,连接默认都是长连接
1、HTTP ⼀般会有 httpd 守护进程,里面可以设置 keep-alive timeout,当 tcp 链接闲置超过这个时间就会关闭, 也可以在 HTTP header 里面设置超时时间
2TCP keep-alive 包含三个参数,支持在系统内核的 net.ipv4 里面设置:当 TCP 链接之后,闲置了 tcp_keepalive_time,则会发送侦测包,如果没有收到对方的 ACK,那么会每隔tcp_keepalive_intvl 再发一次,直到发送了 tcp_keepalive_probes,就会丢弃该链接。
(1tcp_keepalive_intvl = 15
2tcp_keepalive_probes = 5
3tcp_keepalive_time = 1800
实际上 HTTP 没有长短链接,只有 TCP 有,TCP 长连接可以复用⼀个 TCP 链接来发起多次 HTTP 请求,这样可以减少资源消耗,比如⼀次请求 HTML,可能还需要请求后续的 JS/CSS/图⽚等

在交互过程中如果数据传送完了,还不想断开连接怎么办,怎么维持

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

(16)HTTP状态码301302的区别,都有哪些用途?

        ⼀. 301重定向的概念
301重定向(301 Move Permanently),指页面永久性转移,表示为资源或页面永久性地转移到了另⼀个位置。 301HTTP协议中的⼀种状态码,当用户或搜索引擎向服务器发出浏览请求时,服务器返回的HTTP数据流中头信息(header)中包含状态码 301 ,表示该资源已经永久改变了位置。
301重定向是⼀种非常重要的"自动转向“技术,网址重定向最为可行的⼀种方法。
       
         二.  哪些情况需要做301重定向?
网页开发过程中,时常会遇到网站目录结构的调整,将页面转移到⼀个新地址;网页扩展名的改变,这些变化都会 导致网页地址发生改变,此时用户收藏夹和搜索引擎数据库中的旧地址是⼀个错误的地址,访问之后会出现404页面,直接导致网站流量的损失。或者是我们需要多个域名跳转至同⼀个域名,例如本站主站点域名为 www.conimi.com ,而还有⼀个域名www.nico.cc,由于对该域名设置了301重定向,当输⼊www.nico.cc 时,自动跳转至www.conimi.com
        三. 301重定向有什么优点?
有利于网站首选域的确定,对于同⼀资源页面多条路径的301重定向有助于URL权重的集中。例如 www.conimi.com conimi.com 是两个不同的域名,但是指向的内容完全相同,搜索引擎会对两个域名收录情况 不同,这样导致网站权重和排名被分散;对conimi.com 301重定向跳转至www.conimi.com 后,权重和排名集中到www.conimi.com,从而提升自然排名。
        四. 302重定向是什么?
302重定向(302 Move Temporarily),指页面暂时性转移,表示资源或页面暂时转移到另⼀个位置,常被用作网址劫持,容易导致网站降权,严重时网站会被封掉,不推荐使⽤。
        五. 301302的区别
301重定向是页面永久性转移,搜索引擎在抓取新内容的同时也将旧的网址替换成重定向之后的网址;
302重定向是页面暂时性转移,搜索引擎会抓取新的内容而保存旧的网址并认为新的网址只是暂时的。

(17)代理服务器

代理服务器是一种网络实体,它又称为万维网高速缓存。代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时,若代理服务器发现这个请求与暂时存访的请求相同,就返回暂存的响应,而不需要按URL的地址再次去互联网访问该资源。代理服务器可在客户端或服务端工作,也可在中间系统上工作。

(18)长连接与短连接的使用场景

长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况,。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频繁操作情况下需用短连好。

七、HTTPS:CA证书、对称加密、非对称加密

HTTPS (全称:Hyper Text Transfer Protocol over SecureSocket Layer),是以安全为目标的 HTTP 通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性  。HTTPS 在HTTP 的基础下加入SSL,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。         HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层(在 HTTP与 TCP 之间)。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯,例如交易支付等方面 。

端⼝
HTTPURL“http://”起始且默认使⽤端⼝80,⽽HTTPSURL“https://”起始且默认使⽤端⼝443
安全性和资源消耗:
TTP协议运行在TCP之上,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议,SSL/TLS 运行在TCP之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。所以说,HTTP 安全性没有 HTTPS高,但是 HTTPS 比HTTP耗费更多服务器资源。
对称加密:密钥只有一个,加密解密为同一个密码,且加解密速度快,典型的对称加密算法有DESAES等;
非对称加密:密钥成对出现(且根据公钥无法推知私钥,根据私钥也无法推知公钥), 加密解密使用不同密钥(公钥加密需要私钥解密,私钥加密需要公钥解密),相对对称加密速度较慢,典型的非对称加密算法有RSADSA等。
对称密钥加密是指加密和解密使用同一个密钥的方式,这种方式存在的最大问题就是密钥发送问题,即如何安全地将密钥发给对方。
而非对称加密是指使用一对非对称密钥,即公钥和私钥,公钥可以随意发布,但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理,对方接收到加密信息后,使用自己的私钥进行解密。

由于非对称加密的方式不需要发送用来解密的私钥,所以可以保证安全性;但是和对称加密比起来,它非常的慢,所以我们还是要用对称加密来传送消息,但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

(1)HTTPS 的工作过程

1、 客户端发送自己支持的加密规则给服务器,代表告诉服务器要进行连接了;
2、 服务器从中选出⼀套加密算法和 hash 算法以及自己的身份信息(地址等)以证书的形式发送给浏览器,证书中包含服务器信息,加密公钥,证书的办法机构;
3、客户端收到网站的证书之后要做下面的事情:
验证证书的合法性;
验证通过证书,浏览器会生成一串随机数,并用证书中的公钥进行加密;
用约定好的 hash 算法计算握手消息,然后用生成的密钥进行加密,然后⼀起发送给服务器。
4、服务器接收到客户端传送来的信息,要做下面的事情:
4.1 用私钥解析出密码,用密码解析握手消息,验证 hash 值是否和浏览器发来的⼀致;
4.2 使⽤密钥加密消息;
5、如果计算法 hash 值⼀致,握⼿成功。

上面有点绕:HTTPS用对称加密传输内容,但是对称加密的密钥,是非对称加密得到的。客户端申请连接,服务器返回一个公钥,客户端产生密钥,用公钥加密密钥,服务端用私钥解密密钥,得到密钥。

参考:

a.client向server发送请求https://baidu.com,然后连接到server的443端口,发送的信息主要是随机值1和客户端支持的加密算法。
        b.server接收到信息之后给予client响应握手信息,包括随机值2和匹配好的协商加密算法,这个加密算法一定是client发送给server加密算法的子集。
        c.随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面,这套证书其实就是一对公钥和私钥。传送证书,这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间、服务端的公钥,第三方证书认证机构(CA)的签名,服务端的域名信息等内容。
        d.客户端解析证书,这部分工作是由客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随即值(预主秘钥)。
        e.客户端认证证书通过之后,接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
        f.传送加密信息,这部分传送的是用证书加密后的会话秘钥,目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
        g.服务端解密得到随机值1、随机值2和预主秘钥,然后组装会话秘钥,跟客户端会话秘钥相同。
        h.客户端通过会话秘钥加密一条消息发送给服务端,主要验证服务端是否正常接受客户端加密的消息。
        i.同样服务端也会通过会话秘钥加密一条消息回传给客户端,如果客户端能够正常接受的话表明SSL层连接建立完成了。

(2)HTTP与HTTPS的区别

1. 开销:HTTPS 协议需要到 CA 申请证书,⼀般免费证书很少,需要交费;
2. 资源消耗:HTTP 是超文本传输协议,信息是明⽂传输,HTTPS 则是具有安全性的 ssl 加密传输协议,需要消耗更多的 CPU 和内存资源;
3. 端⼝不同:HTTP HTTPS 使用的是完全不同的连接⽅式,用的端口也不⼀样,前者是 80,后者是 443
4. 安全性:HTTP 的连接很简单,是无状态的;HTTPS 协议是由 TSL/SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比HTTP 协议安全
(3)HTTPS 的优缺点?

        优点:
1. 使⽤ HTTPS 协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
2. HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议,要比HTTP 协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性;
3. HTTPS 是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间⼈攻击的成本。
        缺点:
1. HTTPS 协议握⼿阶段比较费时,会使页面的加载时间延长近 50%,增加 10% 20% 的耗电;
2. HTTPS 连接缓存不如 HTTP ⾼效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响;
3. SSL 证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用;
4. SSL 证书通常需要绑定 IP,不能在同⼀ IP 上绑定多个域名,IPv4 资源不可能⽀撑这个消耗;
5. HTTPS 协议的加密范围也比较有限,在⿊客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。
最关键的,SSL 证书的信⽤链体系并不安全,特别是在某些国家可以控制 CA 根证书的情况下,中间人攻击一样可行。

(4)数字签名

为了避免数据在传输过程中被替换,比如黑客修改了你的报文内容,但是你并不知道,所以我们让发送端做⼀个数字签名,把数据的摘要消息进行⼀个加密,比如 MD5,得到⼀个签名,和数据⼀起发送。然后接收端把数据摘要进行MD5 加密,如果和签名⼀样,则说明数据确实是真的。

(5)数字证书

对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但是数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的,CA 证书机构会负责颁发⼀个证书,里面的公钥保证是真的,用户请求服务器时,服务器将证书发给⽤户,这个证书是经由系统内置证书的备案的。

八、HTTP 与 HTTPS的区别

1. 开销:HTTPS 协议需要到 CA 申请证书,⼀般免费证书很少,需要交费;
2. 资源消耗:HTTP 是超文本传输协议,信息是明⽂传输,HTTPS 则是具有安全性的 ssl 加密传输协议,需要消耗更多的 CPU 和内存资源;
3. 端⼝不同:HTTP HTTPS 使用的是完全不同的连接⽅式,用的端口也不⼀样,前者是 80,后者是 443
4. 安全性:HTTP 的连接很简单,是无状态的;HTTPS 协议是由 TSL/SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比HTTP 协议安全

九、在浏览器中输入URL到显示页面的过程

(1)DNS 解析:浏览器查询 DNS,获取域名对应的 IP 地址:具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。对于向本地 DNS 服务器进行查询,如果要查询的域名包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析(此解析具有权威性);如果要查询的域名不由本地 DNS 服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个 IP 地址映射,完成域名解析(此解析不具有权威性)。如果本地域名服务器并未缓存该网址映射关系,那么将根据其设置发起递归查询或者迭代查询;

(2)TCP 连接:浏览器获得域名对应的 IP 地址以后,浏览器向服务器请求建立链接,发起三次握手;

(3)发送 HTTP 请求:TCP 连接建立起来后,浏览器向服务器发送 HTTP 请求;

(4)服务器处理请求并返回 HTTP 报文:服务器接收到这个请求,并根据路径参数映射到特定的请求处理器进行处理,并将处理结果及相应的视图返回给浏览器;

(5)浏览器解析渲染页面:浏览器解析并渲染视图,若遇到对 js 文件、css 文件及图片等静态资源的引用,则重复上述步骤并向服务器请求这些资源;浏览器根据其请求到的资源、数据渲染页面,最终向用户呈现一个完整的页面。

(6)连接结束。

图解:

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

十、DNS解析过程、原理

服务器类型:

根域名服务器

顶级域名服务器

权限域名服务器

本地域名服务器

DNS解析过程:

主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是:如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址,那么本地域名服务器就以 DNS 客户的身份,向根域名服务器继续发出查询请求报文(即替主机继续查询),而不是让主机自己进行下一步查询。因此,递归查询返回的查询结果或者是所要查询的 IP 地址,或者是报错,表示无法查询到所需的 IP 地址。

本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点:当根域名服务器收到本地域名服务器发出的迭代查询请求报文时,要么给出所要查询的 IP 地址,要么告诉本地服务器:“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的 IP 地址告诉本地域名服务器,让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后,要么给出所要查询的 IP 地址,要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后,本地域名服务器得到了所要解析的 IP 地址或报错,然后把这个结果返回给发起查询的主机。

域名缓存:

为了提高 DNS 查询效率,并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量,在域名服务器中广泛使用了高速缓存,用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

由于名字到地址的绑定并不经常改变,为保持高速缓存中的内容正确,域名服务器应为每项内容设置计时器并处理超过合理时间的项(例如:每个项目两天)。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息,就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时,在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销,而减少此时间值可提高域名解析的正确性。

不仅在本地域名服务器中需要高速缓存,在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库,维护存放自己最近使用的域名的高速缓存,并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息,而且主机必须从缓存中删除无效的项。由于域名改动并不频繁,大多数网点不需花精力就能维护数据库的一致性。

DNS使用UDP

PS1:DNS有时也会用TCP,比如解析到的IP太多了,一个响应的UDP包放不下。通常的做法是如果客户端收到一个被截断的UDP响应包,用TCP重新请求一次DNS。UDP不需要建立连接,使得DNS查询速度较快。

PS2:HTTP也不一定就用TCP,可以参考QUIC,它使用UDP来传输HTTP报文,用UDP解决了一些TCP存在的问题,比如队头阻塞之类。

PS3:本质上技术是为场景服务的,当这个技术满足这个场景的时候,就是可以用的。因此从这个角度,没有说DNS一定要用UDP,也没有说HTTP一定要用TCP。

简单说下怎么实现 DNS 劫持

DNS 劫持即域名劫持,是通过将原域名对应的 IP 地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。域名劫持往往只能在特定的网络范围内进行,范围外的 DNS 服务器能够返回正常的 IP 地址。

攻击者可以冒充原域名所属机构,通过电子邮件的方式修改组织机构的域名注册信息,或者将域名转让给其它组织,并将新的域名信息保存在所指定的 DNS 服务器中,从而使得用户无法通过对原域名进行解析来访问目的网址。

具体实施步骤如下:

① 获取要劫持的域名信息:攻击者首先会访问域名查询站点查询要劫持的域名信息。

② 控制域名相应的 E-MAIL 账号:在获取到域名信息后,攻击者通过暴力破解或者专门的方法破解公司注册域名时使用的 E-mail 账号所对应的密码。更高级的攻击者甚至能够直接对 E-mail 进行信息窃取。

③ 修改注册信息:当攻击者破解了 E-MAIL 后,会利用相关的更改功能修改该域名的注册信息,包括域名拥有者信息,DNS 服务器信息等。

④ 使用 E-MAIL 收发确认函:在修改完注册信息后,攻击者在 E-mail 真正拥有者之前收到修改域名注册信息的相关确认信息,并回复确认修改文件,待网络公司恢复已成功修改信件后,攻击者便成功完成 DNS 劫持。

用户端的一些预防手段:

直接通过 IP 地址访问网站,避开 DNS 劫持。
        由于域名劫持往往只能在特定的网络范围内进行,因此一些高级用户可以通过网络设置DNS 指向正常的域名服务器以实现对目的网址的正常访问,例如将计算机首选 DNS 服务器的地址固定为 8.8.8.8。

十一、post与get的区别

GET POST
后退按钮/刷新 无害 数据会被重新提交(浏览器应该告知用户数据会被重新提交)。
书签 可收藏为书签 不可收藏为书签
缓存 能被缓存 不能缓存
编码类型 application/x-www-form-urlencoded application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史 参数保留在浏览器历史中。 参数不会保存在浏览器历史中。
对数据长度的限制 是的。当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。 无限制。
对数据类型的限制 只允许 ASCII 字符。 没有限制。也允许二进制数据。
安全性

与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。

在发送密码或其他敏感信息时绝不要使用 GET !

POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性 数据在 URL 中对所有人都是可见的。 数据不会显示在 URL 中。
        a.使用场景
GET 用于获取资源,而POST 用于传输实体主体。
当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。
        b.参数
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而POST 的参数存储 在实体主体中。不能因为 POST 参数存储在实体主体中就认为它的安全性更⾼,因为照样可以通过⼀些抓包⼯具 (Fiddler)查看。 因为 URL 只⽀持 ASCII 码,因此 GET 的参数中如果存在中⽂等字符就需要先进⾏编码。例如 “中文” 会转换为%E4%B8%AD%E6%96%87 ,而空格会转换为 %20 POST 参数⽀持标准字符集。
        c.安全性
安全的 HTTP 方法不会改变服务器状态,也就是说它只是可读的。
GET 方法是安全的,而POST 却不是,因为 POST 的目的是传送实体主体内容,这个内容可能是用户上传的表单数 据,上传成功之后,服务器可能把这个数据存储到数据库中,因此状态也就发生了改变。
GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied安全的⽅法除了 GET 之外还有:HEADOPTIONS
不安全的⽅法除了 POST 之外还有 PUTDELETE
        d.幂等性
幂等的 HTTP ⽅法,同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是⼀样的。换句话说就是,幂等方法不应该具有副作用(统计用途除外)。
所有的安全方法也都是幂等的。
在正确实现的条件下,GETHEADPUT DELETE 等⽅法都是幂等的,而POST ⽅法不是。
GET /pageX HTTP/1.1 是幂等的,连续调⽤多次,客户端接收到的结果都是⼀样的:
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1Copy to clipboardErrorCopied
POST /add_row HTTP/1.1 不是幂等的,如果调⽤多次,就会增加多⾏记录:
POST /add_row HTTP/1.1 -> Adds a 1nd row
POST /add_row HTTP/1.1 -> Adds a 2nd row
POST /add_row HTTP/1.1 -> Adds a 3rd rowCopy to clipboardErrorCopied
DELETE /idX/delete HTTP/1.1 是幂等的,即使不同的请求接收到的状态码不⼀样:
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1 -> Returns 404Copy to clipboardErrorCopied
        e.可缓存
如果要对响应进行缓存,需要满足以下条件:
请求报文的 HTTP 方法本身是可缓存的,包括 GET HEAD,但是 PUT DELETE 不可缓存,POST 在多数 情况下不可缓存的。
响应报⽂的状态码是可缓存的,包括:200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
响应报⽂的 Cache-Control 首部字段没有指定不进行缓存。
        f.XMLHttpRequest
为了阐述 POST GET 的另⼀个区别,需要先了解 XMLHttpRequest
XMLHttpRequest 是⼀个 API,它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了⼀个通过 URL 来获取数据的简单⽅式,并且不会使整个⻚⾯刷新。这使得⽹⻚只更新⼀部分⻚⾯⽽不会打扰到⽤
户。XMLHttpRequest AJAX 中被⼤量使⽤。
在使⽤ XMLHttpRequest POST ⽅法时,浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这 么做,例如火狐就不会。而GET 方 Header Data 会⼀起发送。

十二、SQL注入

SQL注⼊就是通过把SQL命令插⼊到Web表单提交或输⼊域名或⻚⾯请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
1). SQL注⼊攻击的总体思路
(1). 寻找到SQL注⼊的位置
(2). 判断服务器类型和后台数据库类型
(3). 针对不通的服务器和数据库特点进 行SQL注⼊攻击
2). SQL注⼊攻击实例
比如,在⼀个登录界界,要求输⼊用户名和密码,可以这样输入实现免帐号登录:
用户名: 'or 1 = 1 --
密 码:
用户一旦点击登录,如若没有做特殊处理,那么这个非法用户就很得意的登陆进去了。
下⾯我们分析⼀下:从理论上说,后台认证程序中会有如下的SQL语句:
String sql = "select * from user_table where username=' "+userName+" ' and password=' "+password+" ' " ;
因此,当输入了上面的用户名和密码,上面的SQL语句变成:
SELECT * FROM user_table WHERE username=' 'or 1 = 1 -- and password="
分析上述SQL语句我们知道,username=' ' or 1=1 这个语句⼀定会成功;然后后面加两个-,这意味着注释,它将后面的语句注释,让他们不起作用。这样,上述语句永远都能正确执行,用户轻易骗过系统,获取合法身份。
3). 应对⽅法
(1). 参数绑定
使用预编译⼿段,绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能,攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatismapper文件中,对于传递的参数我们⼀般是使⽤#和 $时,变量就是直接追加在 sql中,⼀般会有sql注⼊问题。
(2). 使用正则表达式过滤传入的参数

十三、XSS攻击

XSS是一种经常出现在web应用中的计算机安全漏洞,与SQL注入一起成为web中最主流的攻击方式。

XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点,进而添加一些脚本代码嵌入到web页面中去,使别的用户访问都会执行相应的嵌入代码,从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

1). XSS攻击的危害

盗取各类用户帐号,如机器登录帐号、用户网银帐号、各类管理员帐号

控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力

盗窃企业重要的具有商业价值的资料

非法转账

强制发送电子邮件

网站挂马

控制受害者机器向其它网站发起攻击

2). 原因解析

主要原因:过于信任客户端提交的数据!

解决办法:不信任任何客户端提交的数据,只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

进一步分析细节:客户端提交的数据本来就是应用所需要的,但是恶意攻击者利用网站对客户端提交数据的信任,在数据中插入一些符号以及javascript代码,那么这些数据将会成为应用代码中的一部分了,那么攻击者就可以肆无忌惮地展开攻击啦,因此我们绝不可以信任任何客户端提交的数据!!!

3). XSS 攻击分类

(1). 反射性XSS攻击 (非持久性XSS攻击)

漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击),例如,正常发送消息:

http://www.test.com/message.php?send=Hello,World!

接收者将会接收信息并显示Hello,World;但是,非正常发送消息:

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>!

接收者接收消息显示的时候将会弹出警告窗口!

(2). 持久性XSS攻击 (留言板场景)

XSS攻击向量(一般指XSS攻击代码)存储在网站数据库,当一个页面被用户打开的时候执行。也就是说,每当用户使用浏览器打开指定页面时,脚本便执行。

与非持久性XSS攻击相比,持久性XSS攻击危害性更大。从名字就可以了解到,持久性XSS攻击就是将攻击代码存入数据库中,然后客户端打开时就执行这些攻击代码。

例如,留言板表单中的表单域:

<input type="text" name="content" value="这里是用户填写的数据">

正常操作流程是:用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板,应用去数据并显示;而非正常操作流程是攻击者在value填写:

<script>alert(‘foolish!’);</script> <!--或者html其他标签(破坏样式。。。)、一段攻击型代码-->

并将数据提交、存储到数据库中;当其他用户取出数据显示的时候,将会执行这些攻击性代码。

4). 修复漏洞方针

漏洞产生的根本原因是 太相信用户提交的数据,对用户所提交的数据过滤不足所导致的,因此解决方案也应该从这个方面入手,具体方案包括:

将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了(如果在cookie中设置了HttpOnly属性,那么通过js脚本将无法读取到cookie信息,这样能有效的防止XSS攻击);

表单数据规定值的类型,例如:年龄应为只能为int、name只能为字母数字组合

对数据进行Html Encode 处理

过滤或移除特殊的Html标签,例如: < script >, < iframe > , < for <, > for>, ” for

过滤JavaScript 事件的标签,例如 “οnclick=”, “onfocus” 等等。

需要注意的是,在有些应用中是允许html标签出现的,甚至是javascript代码出现。因此,我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求(例如输出需要html代码、javascript代码拼接、或者此表单直接允许使用等等),然后区别处理!

十四、粘包和拆包

(1)粘包

如果客户端连续不断的向服务端发送数据包时,服务端接收的数据会出现两个数据包粘在一起的情况。TCP 是基于字节流的,虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块,但是 TCP 把这些数据块仅仅看成一连串无结构的字节流,没有边界;从 TCP 的帧结构也可以看出,在 TCP 的首部没有表示数据长度的字段。

基于上面两点,在使用 TCP 传输数据时,才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息,这种现象即为粘包。

接收端收到了两个数据包,但是这两个数据包要么是不完整的,要么就是多出来一块,这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难,因为无法区分一个完整的数据包。

(2)产生粘包

  • 发送方产生粘包

采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态(一次连接发一次数据不存在粘包),双方在连接不断开的情况下,可以一直传输数据。但当发送的数据包过于的小时,那么 TCP 协议默认的会启用 Nagle 算法,将这些较小的数据包进行合并发送(缓冲区数据发送是一个堆压的过程);这个合并过程就是在发送缓冲区中进行的,也就是说数据发送出来它已经是粘包的状态了。

  • 接收方产生粘包

接收方采用 TCP 协议接收数据时的过程是这样的:数据到接收方,从网络模型的下方传递至传输层,传输层的 TCP 协议处理是将其放置接收缓冲区,然后由应用层来主动获取(C 语言用 recv、read 等函数);这时会出现一个问题,就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来,而下一个数据又到来并有一部分放入的缓冲区末尾,等我们读取数据时就是一个粘包。(放数据的速度 > 应用层拿数据速度)

(3)解决

分包机制一般有两个通用的解决方法:

  1. 特殊字符控制;
  2. 在包头首都添加数据包的长度。

如果使用 netty 的话,就有专门的编码器和解码器解决拆包和粘包问题了。

tips:UDP 没有粘包问题,但是有丢包和乱序。不完整的包是不会有的,收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报,发送的时候既不合并,也不拆分。

十五、forward 和 redirect

Forward 和 Redirect 代表了两种请求转发方式:直接转发和间接转发。

  直接转发方式(Forward):客户端和浏览器只发出一次请求,Servlet、HTML、JSP 或其它信息资源,由第二个信息资源响应该请求,在请求对象 request 中,保存的对象对于每个信息资源是共享的。

间接转发方式(Redirect):实际是两次 HTTP 请求,服务器端在响应第一次请求的时候,让浏览器再向另外一个 URL 发出请求,从而达到转发的目的。

  • 举个通俗的例子: 

直接转发就相当于:“A 找 B 借钱,B 说没有,B 去找 C 借,借到借不到都会把消息传递给 A”;

间接转发就相当于:”A 找 B 借钱,B 说没有,让 A 去找 C 借”。

是servlet的主要两种跳转方式,forward又叫转发,redirect叫重定向

区别(地址栏,数据共享,应用场景,效率,本质,次数)

1、从地址栏显示来说:forward是服务器内部重定向,客户端浏览器的网址不会发生变化;redirect发生一个状态码,告诉服务器去重新请求那个网址,显示的的新的网址

2、数据共享:在定向过程中forward使用的是同一个request,可以共享;redirect不可以。

3、应用场景:forward一般用于用户登录:redirect用于用户注销登录返回主页面或者跳转其他页面

4、forward效率更高

5、本质上说:forward转发是服务器上的行为,而redirect是客户端行为

6、次数:forward只有一次,redirect两次

其他:

一、数据共享方面

forward:转发页面和转发到的页面可以共享request里面的数据
                redirect:不能共享数据

二、地址栏显示方面

forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址.
                redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL.

三、本质区别

转发是服务器行为,重定向是客户端行为。为什么这样说呢,这就要看两个动作的工作流程:

转发过程:客户浏览器发送http请求--->web服务器接受此请求--->调用内部的一个方法在容器内部完成请求处理和转发动作--->将目标资源 发送给客户;在这里,转发的路径必须是同一个web容器下的url,其不能转向到其他的web路径上去,中间传递的是自己的容器内的request。在客 户浏览器路径栏显示的仍然是其第一次访问的路径,也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。

重定向过程:客户浏览器发送http请求--->web服务器接受后发送302状态码响应及对应新的location给客户浏览器--->客户浏览器发现 是302响应,则自动再发送一个新的http请求,请求url是新的location地址--->服务器根据此请求寻找资源并发送给客户。在这里 location可以重定向到任意URL,既然是浏览器重新发出了请求,则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的 路径,客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。

重定向,其实是两次request:第一次,客户端request A,服务器响应,并response回来,告诉浏览器,你应该去B。这个时候IE可以看到地址变了,而且历史的回退按钮也亮了。重定向可以访问自己web应用以外的资源。在重定向的过程中,传输的信息会被丢失。

十六、数字签名、数字证书

(1)数字签名

为了避免数据在传输过程中被替换,比如黑客修改了你的报文内容,但是你并不知道,所以我们让发送端做⼀个数字签名,把数据的摘要消息进行⼀个加密,比如 MD5,得到⼀个签名,和数据⼀起发送。然后接收端把数据摘要进行MD5 加密,如果和签名⼀样,则说明数据确实是真的。

(2)数字证书

对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但是数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的,CA 证书机构会负责颁发⼀个证书,里面的公钥保证是真的,用户请求服务器时,服务器将证书发给⽤户,这个证书是经由系统内置证书的备案的。

十七、滑动窗口

TCP 利用滑动窗口实现流量控制的机制。滑动窗口(Sliding window)是一种流量控制技术。早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。

由于大家不知道网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动窗口机制来解决此问题。

TCP 中采用滑动窗口来进行传输控制,滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时,发送方一般不能再发送数据报,但有两种情况除外,一种情况是可以发送紧急数据,例如,允许用户终止在远端机上的运行进程。

另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。应该是三种报文:零窗口探测报文、带有紧急数据的报文、ack

发送窗口=min(接收窗口,拥塞窗口)

十八、停止等待协议、ARQ 协议

(1)停止等待协议:每发送完一个分组就停止发送,等待对方确认。在收到确认后再发送下一个分组。无差错情况、出现差错(超时重传)、确认丢失和确认迟到

(2)连续ARQ协议:维持发送窗口:位于窗口内的分组都可以连续发送出去而不需要等待对方的确认。

累积确认:接收方不必对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认,这就表示:到这个分组为止的所有分组都已经正确收到啦。优点:容易实现,即使确认丢失也不必重传。缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。

回退N:表示需要再退回来重传已经发送过的N个分组。

十九、CSMA/CD

CSMA/CD即载波侦听多路访问/冲突检测,是广播型信道中采用一种随机访问技术的竞争型访问方法,具有多目标地址的特点。它处于一种总线型局域网结构,其物理拓扑结构正逐步向星型发展。CSMA/CD采用分布式控制方法,所有结点之间不存在控制与被控制的关系。

载波监听多点接入/碰撞检测

根据以上所讨论的,可以把CSMA/CD协议的要点归纳如下:

(1)准备发送:适配器从网络层获得一个分组,加上以太网的首部和尾部,组成以太网帧,放入适配器的缓存中。但在发送之前,必须先检测信道。

(2)检测信道:若检测到信道忙,则应不停地检测,一直等待信道转为空闲。若检测到信道空闲,并在96比特时间内信道保持空闲(保证了帧间最小间隔),就发送这个帧。

(3)在发送过程中仍不停地检测信道,即网络适配器要边发送边监听。这里只有两种可能性:

一是发送成功:在争用期内一直未检测到碰撞。这个帧肯定能够发送成功。发送完毕后,其他什么也不做。然后回到(1)。

二是发送失败:在争用期内检测到碰撞。这时立即停止发送数据,并按规定发送人为干扰信号。适配器接着就执行指数退避算法,等待r倍512比特时间后,返回到步骤(2),继续检测信道。但若重传达16次仍不能成功,则停止重传而向上报错。

以太网每发送完一帧,一定要把已发送的帧暂时保留一下。如果在争用期内检测出发生了碰撞,那么还要在推迟一段时间后再把这个暂时保留的帧重传一次。

二十、PPP

点对点协议(Point to Point Protocol,PPP)为在点对点连接上传输多协议数据包提供了一个标准方法。PPP 最初设计是为两个对等节点之间的 IP 流量传输提供一种封装协议。在 TCP-IP 协议集中它是一种用来同步调制连接的数据链路层协议(OSI模式中的第二层),替代了原来非标准的第二层协议,即 SLIP。除了 IP 以外 PPP 还可以携带其它协议,包括 DECnet 和 Novell 的 Internet 网包交换(IPX)。

点到点协议(Point to Point Protocol,PPP)是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。 [1]  这种链路提供全双工操作,并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据,使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。PPP具有以下功能:
                        (1)PPP具有动态分配IP地址的能力,允许在连接时刻协商IP地址;
                        (2)PPP支持多种网络协议,比如TCP/IP、NetBEUI、NWLINK等;
                        (3)PPP具有错误检测能力,但不具备纠错能力,所以ppp是不可靠传输协议;
                        (4)无重传的机制,网络开销小,速度快。
                        (5)PPP具有身份验证功能。
                        (6) PPP可以用于多种类型的物理介质上,包括串口线、电话线、移动电话和光纤(例如SDH),PPP也用于Internet接入。

        部分组成

封装:一种封装多协议数据报的方法。PPP 封装提供了不同网络层协议同时在同一链路传输的多路复用技术。PPP 封装精心设计,能保持对大多数常用硬件的兼容性,克服了SLIP不足之处的一种多用途、点到点协议,它提供的WAN数据链接封装服务类似于LAN所提供的封闭服务。所以,PPP不仅仅提供帧定界,而且提供协议标识和位级完整性检查服务。

链路控制协议(LCP):一种扩展链路控制协议,用于建立、配置、测试和管理数据链路连接。

网络控制协议(NCP):协商该链路上所传输的数据包格式与类型,建立、配置不同的网络层协议;

配置:使用链路控制协议的简单和自制机制。该机制也应用于其它控制协议,例如:网络控制协议(NCP)

二十一、IPv4、IPv6

(1)IPv4

(2)IPv6

二十二、ARP

二十三、ICMP、IGMP

(1)ICMP

        1. Ping

Ping 是 ICMP 的一个重要应用,主要用来测试两台主机之间的连通性。

Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文,目的主机收到之后会发送 Echo 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

        2. Traceroute

Traceroute 是 ICMP 的另一个应用,用来跟踪一个分组从源点到终点的路径。

Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报,并由目的主机发送终点不可达差错报告报文。

源主机向目的主机发送一连串的 IP 数据报。第一个数据报 P1 的生存时间 TTL 设置为 1,当 P1 到达路径上的第一个路由器 R1 时,R1 收下它并把 TTL 减 1,此时 TTL 等于 0,R1 就把 P1 丢弃,并向源主机发送一个 ICMP 时间超过差错报告报文;

源主机接着发送第二个数据报 P2,并把 TTL 设置为 2。P2 先到达 R1,R1 收下后把 TTL 减 1 再转发给 R2,R2 收下后也把 TTL 减 1,由于此时 TTL 等于 0,R2 就丢弃 P2,并向源主机发送一个 ICMP 时间超过差错报文。

不断执行这样的步骤,直到最后一个数据报刚刚到达目的主机,主机不转发数据报,也不把 TTL 值减 1。但是因为数据报封装的是无法交付的 UDP,因此目的主机要向源主机发送 ICMP 终点不可达差错报告报文。

之后源主机知道了到达目的主机所经过的路由器 IP 地址以及到达每个路由器的往返时间。

    3. ICMP

(1)差错报文:终点不可达、时间超过、参数问题、改变路由、源点抑制

其中终点不可达:网络不可达、主机不可达、协议不可达、端口不可达、需要分片但DF置为1、源路由失败

ICMP差错报文包括IP数据报首部和IP数据部分的前8个字节:对于TCP和UDP而言,可以得到运输层端口号。对于TCP而言还可以得到运输层报文的发送序号。

不应发送ICMP差错报文的几种情况:

①对ICMP差错报告报文,不在发送ICMP差错报告报文

②对第一个分片的数据报片的所有后续数据报片,都不发送ICMP差错报告报文

③对具有多播地址的数据报,都不发送ICMP差错报告报文

④对具有特殊地址的数据报,不发送ICMP差错报文

(2)询问报文:回送请求和回答、时间戳请求和回答

(2)IGMP

二十四、RIP

  RIP使用运输层的用户数据报UDP进行传送。

  UDP数据部分,最长512字节。

二十五、OSPF

直接用IP数据报传送

二十六、BGP

        基于TCP

二十七、SSH

 SSH 为 Secure Shell 的缩写,由 IETF 的网络小组(Network Working Group)所制定;SSH 为建立在应用层基础上的安全协议。SSH 是目前较可靠,专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH在正确使用时可弥补网络中的漏洞。SSH客户端适用于多种平台。几乎所有UNIX平台—包括HP-UX、Linux、AIX、Solaris、Digital UNIX、Irix,以及其他平台,都可运行SSH。

1、功能
  传统的网络服务程序,如:ftp、pop和telnet在本质上都是不安全的,因为它们在网络上用明文传送口令和数据,别有用心的人非常容易就可以截获这些口令和数据。而且,这些服务程序的安全验证方式也是有其弱点的, 就是很容易受到“中间人”这种方式的攻击。所谓“中间人”的攻击方式, 就是“中间人”冒充真正的服务器接收你传给服务器的数据,然后再冒充你把数据传给真正的服务器。服务器和你之间的数据传送被“中间人”一转手做了手脚之后,就会出现很严重的问题。通过使用SSH,你可以把所有传输的数据进行加密,这样”中间人”这种攻击方式就不可能实现了,而且也能够防止DNS欺骗和IP欺骗。使用SSH,还有一个额外的好处就是传输的数据是经过压缩的,所以可以加快传输的速度。SSH有很多功能,它既可以代替Telnet,又可以为FTP、PoP、甚至为PPP提供一个安全的”通道”。

2、验证
  从客户端来看,SSH提供两种级别的安全验证。 
          第一种级别(基于口令的安全验证) 
                  只要你知道自己帐号和口令,就可以登录到远程主机。所有传输的数据都会被加密,但是不能保证你正在连接的服务器就是你想连接的服务器。可能会有别的服务器在冒充真正的服务器,也就是受到“中间人”这种方式的攻击。

          第二种级别(基于密匙的安全验证) 
                  需要依靠密匙,也就是你必须为自己创建一对密匙,并把公用密匙放在需要访问的服务器上。如果你要连接到SSH服务器上,客户端软件就会向服务器发出请求,请求用你的密匙进行安全验证。服务器收到请求之后,先在该服务器上你的主目录下寻找你的公用密匙,然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致,服务器就用公用密匙加密“质询”(challenge)并把它发送给客户端软件。客户端软件收到“质询”之后就可以用你的私人密匙解密再把它发送给服务器。 
                  用这种方式,你必须知道自己密匙的口令。但是,与第一种级别相比,第二种级别不需要在网络上传送口令。 
          第二种级别不仅加密所有传送的数据,而且“中间人”这种攻击方式也是不可能的(因为他没有你的私人密匙)。但是整个登录的过程可能需要10秒。

3、层次
  SSH 主要由三部分组成: 
          传输层协议 [SSH-TRANS] 
          提供了服务器认证,保密性及完整性。此外它有时还提供压缩功能。 SSH-TRANS 通常运行在TCP/IP连接上,也可能用于其它可靠数据流上。 SSH-TRANS 提供了强力的加密技术、密码主机认证及完整性保护。该协议中的认证基于主机,并且该协议不执行用户认证。更高层的用户认证协议可以设计为在此协议之上。

          用户认证协议 [SSH-USERAUTH] 
          用于向服务器提供客户端用户鉴别功能。它运行在传输层协议 SSH-TRANS 上面。当SSH-USERAUTH 开始后,它从低层协议那里接收会话标识符(从第一次密钥交换中的交换哈希H )。会话标识符唯一标识此会话并且适用于标记以证明私钥的所有权。 SSH-USERAUTH 也需要知道低层协议是否提供保密性保护。

          连接协议 [SSH-CONNECT] 
          将多个加密隧道分成逻辑通道。它运行在用户认证协议上。它提供了交互式登录话路、远程命令执行、转发 TCP/IP 连接和转发 X11 连接。

4、结构
  SSH是由客户端和服务端的软件组成的,有两个不兼容的版本分别是:1.x和2.x。 用SSH 2.x的客户程序是不能连接到SSH 1.x的服务程序上去的。OpenSSH 2.x同时支持SSH 1.x和2.x。

服务端是一个守护进程(daemon),他在后台运行并响应来自客户端的连接请求。服务端一般是sshd进程,提供了对远程连接的处理,一般包括公共密钥认证、密钥交换、对称密钥加密和非安全连接。

客户端包含ssh程序以及像scp(远程拷贝)、slogin(远程登陆)、sftp(安全文件传输)等其他的应用程序。

他们的工作机制大致是本地的客户端发送一个连接请求到远程的服务端,服务端检查申请的包和IP地址再发送密钥给SSH的客户端,本地再将密钥发回给服务端,自此连接建立。SSH 1.x和SSH 2.x在连接协议上有一些差异。

一旦建立一个安全传输层连接,客户机就发送一个服务请求。当用户认证完成之后,会发送第二个服务请求。这样就允许新定义的协议可以与上述协议共存。连接协议提供了用途广泛的各种通道,有标准的方法用于建立安全交互式会话外壳和转发(“隧道技术”)专有 TCP/IP 端口和 X11 连接。

  SSH被设计成为工作于自己的基础之上而不利用超级服务器(inetd),虽然可以通过inetd上的tcpd来运行SSH进程,但是这完全没有必要。启动SSH服务器后,sshd运行起来并在默认的22端口进行监听(你可以用 # ps -waux | grep sshd 来查看sshd是否已经被正确的运行了)如果不是通过inetd启动的SSH,那么SSH就将一直等待连接请求。当请求到来的时候SSH守护进程会产生一个子进程,该子进程进行这次的连接处理 。

二十八、DHCP

二十九、大端,小端

  大端模式,是指数据的高字节保存在内存的低地址中,而数据的低字节保存在内存的高地址中,这样的存储模式有点儿类似于把数据当作字符串顺序处理:地址由小向大增加,数据从高位往低位放;这和我们的阅读习惯一致。

  小端模式,是指数据的高字节保存在内存的高地址中,而数据的低字节保存在内存的低地址中,这种存储模式将地址的高低和数据位权有效地结合起来,高地址部分权值高,低地址部分权值低。

下面以unsigned int value = 0x12345678为例,分别看看在两种字节序下其存储情况,我们可以用unsigned char buf[4]来表示value

        Big-Endian: 低地址存放高位,如下:

低地址

---------------

buf[0] (0x12) -- 高位字节

buf[1] (0x34)

buf[2] (0x56)

buf[3] (0x78) -- 低位字节

---------------

高地址

        Little-Endian: 低地址存放低位,如下:

低地址

---------------

buf[0] (0x78) -- 低位字节

buf[1] (0x56)

buf[2] (0x34)

buf[3] (0x12) -- 高位字节

--------------

高地址

内存地址

小端模式存放内容

大端模式存放内容

0x4000

0x78

0x12

0x4001

0x56

0x34

0x4002

0x34

0x56

0x4003

0x12

0x78

为什么会有大端小端:

1. 一开始是由于不同架构的CPU处理多个字节数据的顺序不一样,比如x86的是小段模式,KEIL C51是大端模式。但是后来互联网流行,TCP/IP协议规定为大端模式,为了跨平台通信,还专门出了网络字节序和主机字节序之间的转换接口(ntohs、htons、ntohl、htonl)

2. 大小端模式各有优势:小端模式强制转换类型时不需要调整字节内容,直接截取低字节即可;大端模式由于符号位为第一个字节,很方便判断正负。

三十、IP地址和MAC地址

(1)图解:

 (2)区别

      一、地址长度的不同

1、MAC地址的长度为48位(6个字节),通常表示为12个16进制数,每2个16进制数之间用冒号隔开,如:00:50:29:5A:8H:1E就是一个MAC地址。

2、IP地址为32位,由用点分隔开的4个8八位组构成,如192.168.0.1就是一个IP地址,这种写法叫点分十进制格式。

        二、所在寻址协议层上的区别

1、MAC地址应用在OSI第二层,即数据链路层。数据链路层协议可以使数据从一个节点传递到相同链路的另一个节点上(通过MAC地址)。

2、IP地址应用于OSI第三层,即网络层。网络层协议使数据可以从一个网络传递到另一个网络上(ARP根据目的IP地址,找到中间节点的MAC地址,通过中间节点传送,从而最终到达目的网络)。

交换机不改变帧的MAC地址和IP地址,路由器不改变帧的IP地址,但会改变帧的MAC地址。

        三、 分配依据不同。

1、MAC地址的分配是基于制造商。

MAC地址由网络设备制造商生产时写在硬件内部。这个地址与网络无关,也即无论将带有这个地址的硬件(如集线器、网卡、路由器等)接入到网络的何处,它都有相同的MAC地址,是不可变的。

2、IP地址的分配是基于网络拓朴。

IP地址由网络地址和主机地址两部分组成,分配给这两部分的位数随地址类(A类、B类、C类等)的不同而不同。

三十一、TCP建立连接后,影响传输速度的因素

(1)网络拥塞情况:拥塞窗口、往返时延

(2)流量控制:发送窗口、接收窗口

(3)超时重传时间的选择

(4)TCP发送报文段时机的选择:Nagle算法

(5)糊涂窗口综合征

三十二、syn flood

SYN Flood 又称 SYN 洪水攻击,也是拒绝服务攻击的一种,是一种曾经很经典的攻击方式。攻击者利用TCP协议的安全缺陷,不断发送一系列的SYN请求到目标系统,消耗服务器系统的资源,从而导致目标服务器不响应合法流量请求。

在谈SYN flood 之前,我们先了解一下一次正常的网络请求都有哪些步骤,从而更清晰的了解SYN Flood的攻击方式。

一般一次正常的网络请求分以下几个步骤:

  • 域名解析
  • TCP握手建立链接
  • 客户端发起请求
  • 服务器响应请求
  • 客户端解析并且渲染页面
  • 至此一次请求结束。

而此种攻击正是发生在TCP握手的阶段。TCP握手一般分为三步。客户端发送SYN请求数据包。服务器回复(ACK)确认包。客户端再次回复(ACK)确认包。至此,TCP握手阶段结束。

SYN Flood / SYN 洪水攻击原理

为了创建拒绝服务,攻击者利用的正是TCP协议的安全缺陷。在接收到初始SYN数据包之后,服务器用一个或多个SYN / ACK数据包进行响应,并等待握手中的最后一步。这是它的工作原理。

此种攻击是攻击者向目标服务器发送大量的SYN数据包,服务器会响应每一个请求然后返回ACK确认包,并且等待客户端的最终响应。

因为攻击者通常会采用虚拟ip,所以也就意味着服务器永远不可能接收到最终的确认包。这种情况下当服务器未接收到最终ACK数据包的时候,服务端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接。

这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况(伪造IP地址),那么服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源。从而造成服务器的崩溃,即使你的服务器系统资源够强大,服务端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小)。

此时,正常用户就会觉得服务器失去响应,这种情况就叫做,服务端收到了SYN Flood攻击(SYN 洪水攻击)

在网络中,当服务器断开连接但连接另一端的客户端没有断开连接时,连接被认为是半开的。在这种类型的DDoS攻击中,目标服务器不断离开打开的连接,等待每个连接超时,然后端口再次可用。所以这种攻击也可以被认为是“半开攻击”。

三十三、传输层为什么需要端口号

(1)端口号分类:

服务器端使用的端口号:

熟知端口号:0-1023

登记端口号:1024-49151

客户端使用的端口号:49152-65535

(2)

① TCP端点:套接字socket=(IP地址:端口号),用来唯一标识网络中的一个应用进程。

②、运输层的复用和分用功能的实现依赖于端口号。应用层所有的应用进程都可以通过运输层再传送到IP层,这就是复用。运输层从IP层收到发送给各应用进程的数据后,必须分别交付到指明的各应用进程,这就是分用。

三十四、Nagle 和 Clark

(1)Nagle

要求TCP连接上最多只能有一个未被确认的小分组,在该分组的确认到达之前不能发送其他的小分组

算法过程:

①若发送应用进程把要发送的数据逐个地送到TCP的发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。

②当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。

③只有在收到对前一个报文段的确认后才能继续发送下一个报文段

④、当数据到达较快而网络速率较慢时,用这样的方法可明显减少所用的网络带宽

⑤、当到达的数据已经达到发送窗口大小的一半或者已达到报文段的最大长度,就立即发送一个报文段。

(2)Clark

糊涂窗口综合征:当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢,或二者兼而有之;就会使应用进程间传送的报文段很小,特别是有效载荷很小。极端情况下,有效载荷可能只有1个字节;而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症。

  方案:

1) Clark解决方法。 Clark解决方法是只要有数据到达就发送确认,但宣布的窗口大小为零,直到或者缓存空间已能放入具有最大长度的报文段,或者缓存空间的一半已经空了。
          2 )延迟确认第二个解决方法是延迟一段时间后再发送确认。这表示当一个报文段到达时并不立即发送确认。接收端在确认收到的报文段之前一直等待,直到入缓存有足够的空间为止。延迟的确认防止了发送端的TCP滑动其窗口。当发送端的TCP发送完其数据后,它就停下来了。这样就防止了这种症状。迟延的确认还有另一个优点:它减少了通信量。接收端不需要确认每一个报文段。但它也有一个缺点,就是迟延的确认有可能迫使发送端重传其未被确认的报文段。可以用协议来平衡这个优点和缺点,例如现在定义了确认的延迟不能超过500毫秒。

三十五、如果使用UDP协议,如何保证可靠

UDP不属于连接协议,具有资源消耗少,处理速度快的优点,所以通常音频,视频和普通数据在传送时,使用UDP较多,因为即使丢失少量的包,也不会对接受结果产生较大的影响。

传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理,可靠UDP的简单设计。

  • 1、添加seq/ack机制,确保数据按序发送到对端
  • 2、添加发送和接收缓冲区,缓存刚发送的数据,重传时使用。
  • 3、添加超时重传机制。

详细说明:送端发送数据时,生成一个随机seq=x,然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存,并发送一个ack=x的包,表示对方已经收到了数据。发送端收到了ack包后,删除缓冲区对应的数据。时间到后,定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。分别为*RUDP、RTP、UDT*

开源程序

1、RUDP(Reliable User Datagram Protocol)

        RUDP 提供一组数据服务质量增强机制,如拥塞控制的改进、重发机制及淡化服务器算法等,从而在包丢失和网络拥塞的情况下, RTP 客户机(实时位置)面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时,可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。

2、RTP(Real Time Protocol)

        RTP为数据提供了具有实时特征的端对端传送服务,如在组播或单播网络服务下的交互式视频音频或模拟数据。

应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务;这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式,那么 RTP 可以使用该组播表传输数据到多个目的地。

RTP 本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送,也不确定底层网络的可靠性。 RTP 实行有序传送, RTP 中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,例如:在视频解码中,就不需要顺序解码。

3、UDT(UDP-based Data Transfer Protocol)

基于UDP的数据传输协议(UDP-basedData Transfer Protocol,简称UDT)是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输,而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。

顾名思义,UDT建于UDP之上,并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现,它也可以应用在除了高速数据传输之外的其它应用领域,例如点到点技术(P2P),防火墙穿透,多媒体数据传输等等。

三十六、IPv4分类

这里不至于太过于纠结:A类减去两个网络是因为网络字段号全零表示本网络,网络号为127表示本地软件环回测试本主机的进程之间的通信。B,C类可以用128.0或者192.0.0开始。

主机数减去二,是因为全零主机号表示该IP地址是本主机所连接到的单个网络地址。全1主机字段号表示该网络上的所有主机

专用互联网(本地互联网):

10.0.0.0----10.255.255.255

172.16.0.0----172.31.255.255

192.168.0.0--192.168.255.255

三十七、GET请求中URL编码的意义

我们知道,在GET请求中会对URL中非西文字符进行编码,这样做的目的就是为了 避免歧义。看下面的例子,

针对“name1=value1&name2=value2”的例子,我们来谈一下数据从客户端到服务端的解析过程。首先,上述字符串在计算机中用ASCII吗表示为:

6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C7565326E616D6531:name1 3D:= 76616C756531:value1 26:&6E616D6532:name23D:= 76616C756532:value2 

服务端在接收到该数据后就可以遍历该字节流,一个字节一个字节的吃,当吃到3D这字节后,服务端就知道前面吃得字节表示一个key,再往后吃,如果遇到26,说明从刚才吃的3D到26子节之间的是上一个key的value,以此类推就可以解析出客户端传过来的参数。

现在考虑这样一个问题,如果我们的参数值中就包含 = 或 & 这种特殊字符的时候该怎么办?比如,“name1=value1”,其中value1的值是“va&lu=e1”字符串,那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样,我们的本意是只有一个键值对,但是服务端却会解析成两个键值对,这样就产生了歧义。

那么,如何解决上述问题带来的歧义呢?解决的办法就是对参数进行URL编码:例如,我们对上述会产生歧义的字符进行URL编码后结果:“name1=va%26lu%3De1”,这样服务端会把紧跟在“%”后的字节当成普通的字节,就是不会把它当成各个参数或键值对的分隔符

三十八、多播

三十九、为什么有了mac地址还要用ip地址/为什么有了ip地址还要mac地址

①、网络分层实现。mac地址在数据链路层,ip地址在网络层。mac是数据链路层使用的地址,其上不一定都是ip地址。ip是网络层使用的地址,其下也不一定都是mac地址。

②、如果只有链路层而没有网络层,那么整个通讯就是一张没有路由的大网,一个人找一台主机就要广播给全网主机,这显然是不可能的。网络层就能将链路层的广播域划分开,通过路由表决定数据走向。

③、mac地址杂乱无章,若不用ip地址,则整个网络在数据链路层链接在一起,那么转发表将非常大。

四十、http3.0

1. TCP队头阻塞

TCP数据包是有序传输,中间一个数据包丢失,会等待该数据包重传,造成后面的数据包的阻塞。

2. HTTP队头阻塞

http队头阻塞和TCP队头阻塞完全不是一回事。

http1.x采用长连接(Connection:keep-alive),可以在一个TCP请求上,发送多个http请求。

有非管道化和管道化,两种方式。

                非管道化,完全串行执行,请求->响应->请求->响应...,后一个请求必须在前一个响应之后发送。

                管道化,请求可以并行发出,但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是,没有序号标明顺序,只能串行接收。

管道化请求的致命弱点:

1. 会造成队头阻塞,前一个响应未及时返回,后面的响应被阻塞
        2. 请求必须是幂等请求,不能修改资源。因为,意外中断时候,客户端需要把未收到响应的请求重发,非幂等请求,会造成资源破坏。

由于这个原因,目前大部分浏览器和Web服务器,都关闭了管道化,采用非管道化模式。

无论是非管道化还是管道化,都会造成队头阻塞(请求阻塞)。

解决http队头阻塞的方法:

        1. 并发TCP连接(浏览器一个域名采用6-8个TCP连接,并发HTTP请求)
        2. 域名分片(多个域名,可以建立更多的TCP连接,从而提高HTTP请求的并发)

3. HTTP2方式

http2使用一个域名单一TCP连接发送请求,请求包被二进制分帧,不同请求可以互相穿插,避免了http层面的请求队头阻塞。但是不能避免TCP层面的队头阻塞。

4.HTTP3.0

回顾HTTP2.0

HTTP1.1在应用层以纯文本的形式进行通信,每次通信都要带完整的HTTP的头,而且不考虑pipeli模式的化,每次的过程总是像上面描述的那样一去一回。那样在实时性、并发想上都存在问题

头部压缩:HTTP2.0会对HTTP的头进行一定的压缩,将原来每次都要携带的大量key value在两端建立一个索引表,对相同的头只发送索引表中的索引

HTTP2.0协议将一个TCP的连接中,切分成多个流。每个流都有自己的ID,而且流可以是客户端发服务端,也可以是服务端发客户端,它其实只是一个虚拟的通道。流是有优先级的

HTTP2.0还将所有的传输信息分割为更小的信息和帧,并对它们采用二进制格式编码。常见的帧有Header帧,用于传输Header内容,并且会开启一个新的流,再就是Data帧,用来传输正文实体。多个Data帧属于一个流

通过这两种机制,http2.0的客户端可以将对个请求不同的流中,然后将请求内容拆成帧,进行二进制传输。这些真可以打散乱序发送,然后根据每个帧首部的流标识符重新组装,并且可以根据优先级,决定先处理那个流的数据

二进制传输就是以上

例子:

假设一个页面要发送三个独立的请求,一个获取css,一个获取js,一个获取图片jpg。如果使用HTTP1.1就是串行的,但是如果使用HTTP2.0,就可以在一个连接里,客户端和服务端都可以同时发送多个请求或回应,而且不用按照顺序一对一对应

http2.0成功解决了http1.1的队首阻塞问题,同时,也不需要通过http1.x的pipeline机制用多条tcp连接来实现并行请求和响应;减少了tcp连接数对服务器性能的影响,同时将页面的多个数据css,js,jpg等通过一个数据链接进行传输,能够加快页面组件的传输速度。

QUIC协议

HTTP2.0 也是基于TCP协议的,tcp协议在处理包时是有严格顺序的

当其中一个数据包遇到问题,TCP连接需要等待找个包完成重传之后才能继续进行,虽然HTTP2.0通过多个stream,使得逻辑上一个tcp连接上的并行内容,进行多路数据的传输,然而这中间没有关联的数据,一前一后,前面stream2的帧没有收到,后面stream1的帧也会因此堵塞

于是google的 QUIC协议从TCP切换到UDP

  • 机制一:自定义连接机制
    一条tcp连接是由四元组标识的,分别是源ip、源端口、目的ip、目的端口,一旦一个元素发生变化时,就会断开重连,重新连接。在次进行三次握手,导致一定的延时

在TCP是没有办法的,但是基于UDP,就可以在QUIC自己的逻辑里面维护连接的机制,不再以四元组标识,而是以一个64位的随机数作为ID来标识,而且UDP是无连接的,所以当ip或者端口变化的时候,只要ID不变,就不需要重新建立连接

  • 机制二:自定义重传机制
    tcp为了保证可靠性,通过使用序号和应答机制,来解决顺序问题和丢包问题

任何一个序号的包发过去,都要在一定的时间内得到应答,否则一旦超时,就会重发这个序号的包,通过自适应重传算法(通过采样往返时间RTT不断调整)

但是,在TCP里面超时的采样存在不准确的问题。例如发送一个包,序号100,发现没有返回,于是在发送一个100,过一阵返回ACK101.客户端收到了,但是往返的时间是多少,没法计算。是ACK到达的时候减去第一还是第二。

QUIC也有个序列号,是递增的,任何宇哥序列号的包只发送一次,下次就要加1,那样就计算可以准确了

但是有一个问题,就是怎么知道包100和包101发送的是同样的内容呢?quic定义了一个offset概念。QUIC既然是面向连接的,也就像TCP一样,是一个数据流,发送的数据在这个数据流里面有个偏移量offset,可以通过offset查看数据发送到了那里,这样只有这个offset的包没有来,就要重发。如果来了,按照offset拼接,还是能够拼成一个流。

  • 机制三: 无阻塞的多路复用

有了自定义的连接和重传机制,就可以解决上面HTTP2.0的多路复用问题

同HTTP2.0一样,同一条 QUIC连接上可以创建多个stream,来发送多个HTTP请求,但是,QUIC是基于UDP的,一个连接上的多个stream之间没有依赖。这样,假如stream2丢了一个UDP包,后面跟着stream3的一个UDP包,虽然stream2的那个包需要重新传,但是stream3的包无需等待,就可以发给用户。

  • 机制四:自定义流量控制

TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update,来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的,不但在一个连接上控制窗口,还在一个连接中的每个steam控制窗口。

在TCP协议中,接收端的窗口的起始点是下一个要接收并且ACK的包,即便后来的包都到了,放在缓存里面,窗口也不能右移,因为TCP的ACK机制是基于序列号的累计应答,一旦ACK了一个序列号,就说明前面的都到了,所以是要前面的没到,后面的到了也不能ACK,就会导致后面的到了,也有可能超时重传,浪费带宽

QUIC的ACK是基于offset的,每个offset的包来了,进了缓存,就可以应答,应答后就不会重发,中间的空档会等待到来或者重发,而窗口的起始位置为当前收到的最大offset,从这个offset到当前的stream所能容纳的最大缓存,是真正的窗口的大小,显然,那样更加准确。

字节面试杂谈——计算机网络原理相关推荐

  1. 字节面试杂谈——操作系统

    目录 一.操作系统的定义 二.系统调用.用户态和核心态 三.进程和线程的区别,结合JAVA JVM运行时内存 四.进程的状态 五.进程间的通信方式 六.线程间的同步方式 七.进程的调度算法 八.内存管 ...

  2. 字节面试杂谈——MySQL、Redis

    目录 一.架构:Server层,引擎层 二.引擎:InnoDB,MyISAM 三.聚簇索引和非聚簇索引 四.事务及其四大特性.MySQL中事务提交的过程 五.并发事务带来的问题 六.事务的隔离级别 七 ...

  3. 计算机网络原理超详解说

    计算机网络原理超详解说 前言 大家好,我是泰斗贤若如,一个专注于用大白话讲解技术的号主,这次给大家分享计算机网络原理的相关知识,我自认为文章内容已经很通俗易懂了,祝您阅读愉快! 一.计算机网络概述 时 ...

  4. 计算机网络原理第一章习题3-24 3-25

    计算机网络原理第一章习题 3-24假定站点A和B在同一个10Mb/s以太网网段上.这两个站点之间的传播时延为225比特时间.现假定A开始发送一帧,并且在A发送结束之前B也发送一帧.如果A发送的是以太网 ...

  5. 原理 msc_计算机网络原理梳理丨无线与移动网络

    目录 无线网络 移动网络 IEEE802.11 蜂窝网络 移动IP网络 其它典型无线网络介绍 无线网络 无线网络的基本结构 无线主机 无线链路 基站 网络基础设施 自组织网络(Ad Hoc网络) 无线 ...

  6. 因特网上的计算机通常使用的网络协议为,计算机网络原理自考2015年10月真题

    计算机网络原理自考2015年10月真题及答案解析 本试卷为单选题型,填空题,简答,计算等题型. 一.单项选择题(本大题共24小题,每小题1分,共24分) 1.局域网LAN一般采用的传输方式为 A.&q ...

  7. 计算机网络8832,2021年4月份自学考试计算机网络原理04741答案.doc

    注:此试卷只有部分答案,为本人所做,假如错误,敬请原谅. 绝密★考试结束前 全国 4月高等教育自学考试 计算机网络原理试题 课程代码:04741 请考生按要求用笔将全部试题答案涂.写在答题纸上. 选择 ...

  8. 湎计算机网络通讯设备有哪些,2018年4月自考计算机网络原理04741试题及答案

    <2018年4月自考计算机网络原理04741试题及答案>由会员分享,可在线阅读,更多相关<2018年4月自考计算机网络原理04741试题及答案(9页珍藏版)>请在人人文库网上搜 ...

  9. [渝粤教育] 信阳师范学院 计算机网络原理 参考 资料

    教育 -计算机网络原理-章节资料考试资料-信阳师范学院[] 第一章作业 第一章单元测验 1.[单选题]计算机网络分为广域网.局域网和城域网,其划分的主要依据是() A.网络的作用范围 B.网络的拓扑结 ...

最新文章

  1. 常见NoSQL系统使用场景分析
  2. 网页打印问题,打印设置,打印预览,打印分页,纵打,横打及页面的边距
  3. 兼顾隐私与权利,华为以“科技有道”,实现“隐私无价”
  4. 从Java新手到大神需要学哪些知识?
  5. 计算机网络应用云计算,计算机网络云计算的类型
  6. geth运行报错zsh: exec format error: ./geth
  7. 顺序链表,动态数组实现
  8. java工程师的关键绩效指标_绩效考核表(JAVA高级工程师)
  9. c语言课程设计作业医院挂号系统,【c语言课程设计】医院门诊系统
  10. 【数学建模】CUMCM-2017A CT系统参数标定及成像 思路及部分代码
  11. html在线快递单号打印,HTML 快递打印模板(示例代码)
  12. 京东联盟API接口-京东订单查询接口-实时掌握订单情况
  13. Real-time Intended Knee Joint Motion Prediction by deep-recurrent neural networks利用深度递归神经网络实时预测膝关节运动
  14. 更好的 java 重试框架 sisyphus 配置的 2 种方式介绍
  15. 6个常见的API接口在线管理平台
  16. Javascript正则表达式表示固定开头和结尾的字符串
  17. Android刘海屏、水滴屏全面屏适配详解,997页字节跳动Android面试真题解析火爆全网
  18. 大数据——Flume组件Source、Channel和Sink具体使用
  19. word中设置奇偶页页眉页脚
  20. 零样本分割系列论文(2)Open-Vocabulary Instance Segmentation via Robust Cross-Modal Pseudo-Labeling

热门文章

  1. 从Github下载laravel项目遇到的坑
  2. Python学习笔记字典之检查字典中是否存在键或值
  3. R语言 RevoScaleR的大规模数据集决策树模型应用案例
  4. linux虚拟机怎么联网
  5. 如何安装My SQL
  6. Kotlin入门第四节
  7. 浏览器无法访问某个网站,其他网站都正常
  8. qt网络编程及readyread信号
  9. [转]Win10 莫名卡顿问题解决(1903-1909版本)
  10. 中断系统应用实例(1)用定时器T1工作方式1控制两个LED以不同周期闪烁