计算机网络相关知识点总结
标签:网络协议(TCP/IP四层五层协议、OSI七层协议)、HTTP协议、TCP协议、UDP协议
对萌新的计算机网络详解
对大佬的计算机网络简介
(内容总结至网络上各类资料)
网络7层协议
计算机与网络设备要相互通信,双方就必须基于相同的方法。比如,如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信,所有的这一切都需要一种规则。而我们就把这种规则称为协议(protocol)。
OSI七层模型:
各层简介
解决两个硬件之间怎么通信的问题,常见的物理媒介有光纤、电缆、中继器等。它主要定义物理设备标准,如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。
它的主要作用是传输比特流(就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0,也就是我们常说的数模转换与模数转换)。这一层的数据叫做比特。
建立逻辑连接、进行硬件地址寻址、差错校验 [3] 等功能。(由底层网络定义协议)
将比特组合成字节进而组合成帧,用MAC地址访问介质,错误发现但不能纠正。
在计算机网络中由于各种干扰的存在,物理链路是不可靠的。该层的主要功能就是:通过各种控制协议,将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。
它的具体工作是接收来自物理层的位流形式的数据,并封装成帧,传送到上一层;同样,也将来自上层的数据帧,拆装为位流形式的数据转发到物理层。这一层的数据叫做帧。
进行逻辑地址寻址,实现不同网络之间的路径选择。
计算机网络中如果有多台计算机,怎么找到要发的那台?如果中间有多个节点,怎么选择路径?这就是路由要做的事。
该层的主要任务就是:通过路由选择算法,为报文(该层的数据单位,由上一层数据打包而来)通过通信子网选择最适当的路径。这一层定义的是IP地址,通过IP地址寻址,所以产生了IP协议。
协议有:ICMP IGMP IP(IPV4 IPV6)
定义传输数据的协议端口号,以及流控和差错校验。
当发送大量数据时,很可能会出现丢包的情况,另一台电脑要告诉是否完整接收到全部的包。如果缺了,就告诉丢了哪些包,然后再发一次,直至全部接收为止。
简单来说,传输层的主要功能就是:监控数据传输服务的质量,保证报文的正确传输。
协议有:TCP UDP,数据包一旦离开网卡即进入网络传输层
建立、管理、终止会话。(在五层模型里面已经合并到了应用层)
虽然已经可以实现给正确的计算机,发送正确的封装过后的信息了。但我们总不可能每次都要调用传输层协议去打包,然后再调用IP协议去找路由,所以我们要建立一个自动收发包,自动寻址的功能。于是会话层出现了:它的作用就是建立和管理应用程序之间的通信。
对应主机进程,指本地主机与远程主机正在进行的会话
数据的表示、安全、压缩。(在五层模型里面已经合并到了应用层)
表示层负责数据格式的转换,将应用处理的信息转换为适合网络传输的格式,或者将来自下一层的数据转换为上层能处理的格式。
格式有,JPEG、ASCll、EBCDIC、加密格式等
网络服务与最终用户的一个接口。
应用层是计算机用户,以及各种应用程序和网络之间的接口,其功能是直接向用户提供服务,完成用户希望在网络上完成的各种工作。
协议有:HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
数据传输介绍
箭头表示了数据传输方向
| 输出 | 输入 |
---|
应用层 | 人做好信息,往下发↓ | 看信息信息↑ | 表示层 | 翻译一下(加密)↓ | 翻译一下↑ | 会话层 | 打包↓ | 看看包送全了没,没全就叫送缺的那个↑ | 传输层 | 把包发给下层↓ | 把包发给下层↑ | 网络层 报文 | 给包贴个ip地址的标签↓ | 整合成包,看看送对了没↑ | 数据链路层 帧 | 查表ip转mac,然后转成电信号↓ | 整理成帧,看看全不全,送上去↑ | 物理层 | 定义好各种信号的意思,线路和插口的格式,发送吧→ | 收到信号,送上去↑ |
TCP/IP协议
横向对比下TCP/IP4层模型、5层模型和OSI七层模型的差别
常见协议说明
HTTP协议(应用层)
HTTP协议(超文本传输协议),处于应用层
规定了双方发送数据的格式,以及交互规则
基于HTTP协议的client与server请求包含4个过程: 1.建立TCP套接字连接; 2.发送HTTP请求报文; 3.接收HTTP应答/响应报文; 4.关闭TCP套接字连接。
请求与响应
一问一答,请求一次,响应一次,没有请求服务器会断开连接
由于HTTP报文是面向文本的,因此报文中的每一个字段都是一些ASCII码串,但各个字段的长度是不确定的。 HTTP有两类报文:请求报文和响应报文。
HTTP请求报文
一个HTTP请求分为三部分组成:请求行,消息头,消息正文
请求行
请求行分为三部分:请求方式、资源路径、协议,最后有个(CRLF)
method url protocol(CRLF)
例如:
GET /index.html HTTP/1.1(CRLF)
请求行以CRLF结束 CR:回车符,asc编码中对应数字13 LF:换行符,asc编码中对应数字10
请求方式
GET:请求获取Request-URI所标识的资源 POST:在Request-URI所标识的资源后附加新的数据 HEAD:请求获取由Request-URI所标识的资源的响应消息报头 PUT:请求服务器存储一个资源,并用Request-URI作为其标识 DELETE:请求服务器删除Request-URI所标识的资源 TRACE:请求服务器回送收到的请求信息,主要用于测试或诊断 CONNECT:保留将来使用 OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项和需求 常用的为GET何POST方法
消息头
消息头由若干行表示,每行表示一个具体的头信息 key/value键值对组成,每行一对,关键字和值用英文冒号“:”分隔。 每个头信息格式分为两部分: name消息头名字:value消息头的值(CRLF) 每个消息头都以CRLF结尾
最后一个消息头结尾处会有两个CRLF,第一个表示最后一个消息头结束,第二个表示消息头这整部分结束,通知服务器以下不再有请求头信息
请求头部由请求头部通知服务器有关于客户端请求的信息,典型的请求头有: User-Agent:产生请求的浏览器类型。 Accept:客户端可识别的内容类型列表。 Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
例如:
Host: localhost:8080(CRLF)
Connection: keep-alive(CRLF)
Cache-Control: max-age=0(CRLF)
Upgrade-Insecure-Requests: 1(CRLF)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36(CRLF)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8(CRLF)
Accept-Encoding: gzip, deflate, sdch(CRLF)
Accept-Language: zh-CN,zh;q=0.8(CRLF)(CRLF)
消息正文
请求数据是在POST方法中使用。 POST方法适用于需要客户填写表单的场合。 与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
正文部分不是必须部分,消息正文是2进制数据 是客户端在发送请求时发送给服务端客户提交的数据 这些数据可能是注册信息,上传的图片等 具体数据是什么类型以及这些2进制数据有多少字节会在消息头中具体说明 若消息头中没有说明消息正文内容则这个请求中是不含有正文的
下面是浏览器发送给服务端的一个请求(不含有正文部分)
GET /index.html HTTP/1.1CRLF
Host: localhost:8080
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
HTTP响应
HTTP响应格式也分为三部分:状态行、响应头、响应正文
状态行格式
protorol status-code status-reason 协议版本 状态码 状态描述
响应状态码有三位数字组成,第一个数字定义了响应的类别,且有五种可能取值: 1xx:信息响应类,表示接受到请求并继续处理 2xx:处理成功响应类,表示动作被成功接收兵处理 3xx:重定向类,为了完成指定的动作,必须接受下一步处理 4xx:客户端错误类,表示客户端请求包含错误的语法或不能 正确的执行 5xx:服务端错误类,服务端不能正确的处理一个正确的请求。
常见的: 200:OK,一切正常 302:服务端要求客户端重定向到指定路径 400:Bad Request,客户端请求有语法错误,不能被服务器所理解 401:Unauthorized,请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用 403:Forbidden,服务器收到请求,但是拒绝提供服务 404:Not Found,用于请求资源未找到 500:Internal Server Error,服务端处理异常 503:Server Unavailable,服务器当前不能处理客户端的请求,一段时间后可能恢复正常**
响应头格式
响应头的格式与请求中的消息头格式一致。
响应正文
响应正文也是二进制数据,消息报头与请求报头类似, 不同在于请求报头附带的是关于请求的相关信息,而消息报头则附带的是服务端应答的相关信息。 是用于将客户端请求的资源等信息发送回给客户端。
该正文具体表示的介质类型以及占用的字节长度会在响应头中有所描述。
一个HTTP响应大致内容: HTTP/1.1 200 OK(CRLF) Content-Type:text/html(CRLF) Content-Length:224586(CRLF)(CRLF) 1101010101001…2进制字节数据
tomcat工作整体流程
- 解析请求
- 处理请求
- 发送响应
HTML中提交请求的方式
form表单
作用是将用户输入的内容提交给服务端的 只有包含在form表单中的<input>内容会被提交 这一点需要注意: form有两个重要属性: action:用来指定表单提交的位置 method:用来指定表单提交的形式
提交形式有两种
GET:地址栏形式提交,所有表单中的内容会拼接到url中被提交, 此方式只能提交文本类型数据 POST:打包提交形式,提交的内容会被包含在请求的消息中 如果含有用户隐私信息,如密码或者含有附件时,应当使用POST
TCP与UDP(传输层)
UDP
UDP协议全称是用户数据报协议,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在第四层传输层,处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。
它有以下几个特点:
1. 面向无连接
首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的,想发数据就可以开始发送了。并且也只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。
具体来说就是:
- 在发送端,应用层将数据传递给传输层的 UDP 协议,UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议,然后就传递给网络层了
- 在接收端,网络层将数据传递给传输层,UDP 只去除 IP 报文头就传递给应用层,不会任何拼接操作
2. 有单播,多播,广播的功能
UDP 不止支持一对一的传输方式,同样支持一对多,多对多,多对一的方式,也就是说 UDP 提供了单播,多播,广播的功能。
3. UDP是面向报文的
发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此,应用程序必须选择合适大小的报文
4. 不可靠性
首先不可靠性体现在无连接上,通信都不需要建立连接,想发就发,这样的情况肯定不可靠。
并且收到什么数据就传递什么数据,并且也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据了。
再者网络环境时好时坏,但是 UDP 因为没有拥塞控制,一直会以恒定的速度发送数据。即使网络条件不好,也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包,但是优点也很明显,在某些实时性要求高的场景(比如电话会议)就需要使用 UDP 而不是 TCP。
UDP只会把想发的数据报文一股脑的丢给对方,并不在意数据有无安全完整到达。
5. 头部开销小,传输数据报文时是很高效的。
UDP 头部包含了以下几个数据:
- 两个十六位的端口号,分别为源端口(可选字段)和目标端口
- 整个数据报文的长度
- 整个数据报文的检验和(IPv4 可选 字段),该字段用于发现头部信息和数据中的错误
因此 UDP 的头部开销小,只有八字节,相比 TCP 的至少二十字节要少得多,在传输数据报文时是很高效的
TCP
当一台计算机想要与另一台计算机通讯时,两台计算机之间的通信需要畅通且可靠,这样才能保证正确收发数据。例如,当你想查看网页或查看电子邮件时,希望完整且按顺序查看网页,而不丢失任何内容。当你下载文件时,希望获得的是完整的文件,而不仅仅是文件的一部分,因为如果数据丢失或乱序,都不是你希望得到的结果,于是就用到了TCP。
TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议,由 IETF 的RFC 793定义。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构,你可以把它想象成排水管中的水流。
1. TCP连接过程-三次握手
如下图所示,可以看到建立一个TCP连接的过程为(三次握手的过程):
第一次握手
客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后,客户端便进入 SYN-SENT 状态。
第二次握手
服务端收到连接请求报文段后,如果同意连接,则会发送一个应答,该应答中也会包含自身的数据通讯初始序号,发送完成后便进入 SYN-RECEIVED 状态。
第三次握手
当客户端收到连接同意的应答后,还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态,服务端收到这个应答后也进入 ESTABLISHED 状态,此时连接建立成功。
这里可能大家会有个疑惑:为什么 TCP 建立连接需要三次握手,而不是两次?这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况,从而产生错误。
总结:
三次握手可以理解为网络聊天
①A→B:在吗? ②B→A:在呢 ③A→B:阿吧阿巴阿巴阿八阿巴阿巴阿八阿吧…
2.断开连接的四次挥手
TCP 是全双工的,在断开连接时两端都需要发送 FIN 和 ACK。
第一次挥手
户端 A 认为数据发送完成,则它需要向服务端 B 发送连接释放请求。
第二次挥手
B 收到连接释放请求后,会告诉应用层要释放 TCP 链接。然后会发送 ACK 包,并进入 CLOSE_WAIT 状态,此时表明 A 到 B 的连接已经释放,不再接收 A 发的数据了。但是因为 TCP 连接是双向的,所以 B 仍旧可以发送数据给 A。
第三次挥手
B 如果此时还有没发完的数据会继续发送,完毕后会向 A 发送连接释放请求,然后 B 便进入 LAST-ACK 状态。
第四次挥手
A 收到释放请求后,向 B 发送确认应答,此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL(最大段生存期,指报文段在网络中生存的时间,超时会被抛弃) 时间,若该时间段内没有 B 的重发请求的话,就进入 CLOSED 状态。当 B 收到确认应答后,也便进入 CLOSED 状态。
3. TCP协议的特点
每条TCP传输连接只能有两个端点,只能进行点对点的数据传输,不支持多播和广播传输方式。
TCP不像UDP一样那样一个个报文独立地传输,而是在不保留报文边界的情况下以字节流方式进行传输。
当网络出现拥塞的时候,TCP能够减小向网络注入数据的速率和数量,缓解拥塞
TCP允许通信双方的应用程序在任何时候都能发送数据,因为TCP连接的两端都设有缓存,用来临时存放双向通信的数据。当然,TCP可以立即发送一个数据段,也可以缓存一段时间以便一次发送更多的数据段(最大的数据段大小取决于MSS)
TCP和UDP的比较
1. 对比
| UDP | TCP |
---|
是否连接 | 无连接 | 面向连接 | 是否可靠 | 不可靠传输,不使用流量控制和拥塞控制 | 可靠传输,使用流量控制和拥塞控制 | 连接对象个数 | 支持一对一,一对多,多对一和多对多交互通信 | 只能是一对一通信 | 传输方式 | 面向报文 | 面向字节流 | 首部开销 | 首部开销小,仅8字节 | 首部最小20字节,最大60字节 | 适用场景 | 适用于实时应用(IP电话、视频会议、直播、在线网络游戏对战等) | 适用于要求可靠传输的应用,例如文件传输、游戏充值等 |
2. 总结
- TCP向上层提供面向连接的可靠服务 ,UDP向上层提供无连接不可靠服务。
- 虽然 UDP 并没有 TCP 传输来的准确,但是也能在很多实时性要求高的地方有所作为
- 对数据准确性要求高,速度可以相对较慢的,可以选用TCP
|