计算机网络
计算机网络体系
- 五层协议
- 应用层:为特定应用程序提供数据传输服务,如HTTP,DNS,SMTP等,数据单位是报文。
- 传输层:提供的是进程间的通用数据传输服务,由于应用层协议很多,因此定义通用的传输层协议就可以支持所有
的应用层协议,包括两种主要协议:- 传输控制协议:TCP,面向连接的,可靠的数据传输协议,数据单位是报文段,其主要提供完整性服务。
- 用户数据报协议:UDP,面向无连接的,尽最大努力传输的,不可靠的数据传输协议,数据单位是用户数据
报,其主要提供及时性服务 - 传输层中的端口是用来区分同一主机上的不同进程。常见的应用端口有:
应用程序 | FTP | SSH | TELNET | SMTP | HTTP | HTTPS | DNS |
---|---|---|---|---|---|---|---|
端口 | 21 | 22 | 23 | 24 | 80 | 443 | 53 |
- 网络层:为了能够为处于不同地理位置的两个不同网络上的主机提供数据传输服务,网络层将传输层传递下来的报
文段或者用户数据报封装成组,主要协议有IP,ICMP(Internet控制报文协议),RIP,OSPF,BGP,IGMP(Internet组管理
协议)等。 - 数据链路层:由于两个相邻节点之间可能存在多条逻辑链路,因此数据链路层的作用是用来为相邻节点之间寻找一
条合适的逻辑链路。其基本问题有:- 封装成帧:给网络层传递下来的数据分组前后加上首部和尾部,构成一个帧。
- 透明传输:上一层传输下来的数据中如果含有本层封装成帧所使用的帧定界符如SOT,EOT时,就会设法消除这
种歧义,这使得什么样的字符数据都可以放在帧中传输。解决办法就是在控制字符前加入一个转义字符ESC,如
果转义字符也出现在数据中,就在转移字符前再加一个转义字符,接收端在收到连续的两个转义字符时就删除
前面的一个。 - 差错检测:
a) 比特差错:循环冗余检验CRC
b) 帧差错:出现帧重复,帧失序,帧丢失。
- 物理层:定义了物理设备的标准,如网线的接口类型,各种介质的传输速率,比特的表示等,以此来屏蔽传输媒体
和通信手段的差异。 - 数据传输格式的变化:报文(应用层)->数据报(传输层)->分组(网络层)->数据帧(数据链路层)->比特流(物
理层)
- 七层协议
- 表示层:数据压缩,加密以及数据描述等
- 会话层:建立和管理会话
- 在五层协议中,上面两层的功能由应用程序开发者自行处理
- TCP/IP
- 此时应用层可能会直接使用IP层或者传输层
- ICMP:Internet控制报文协议,其基于IP协议工作的,也就是服务于IP协议的,其用于确认IP包是否成功到达目标地址,以及通知发送过程IP包被丢弃的原因,通过返回的ICMP报文中的代码可以判断IP包的传送情况,比如3表示目标不可达,11表示超时等。常用的用于验证网络连通性的ping命令和获取IP包转发节点信息的traceroute命令就是基于该协议实现的。
TCP/UDP的特点
- UDP是面向无连接的,尽最大努力交付,不可靠传输数据的,其没有拥塞控制,对于应用程序传下来的报文不合并也不拆分,只是添加UDP首部,支持一对多,多对一,多对多的交互通信。
- TCP是面向连接的,提供可靠的服务,有流量控制和拥塞控制,面向字节流。把应用层传下来的报文看成字节流,把字节流组织成大小不一的数据块,每一条TCP连接只能是一对一的。
- UDP报文段格式:
- UDP的首部只有8字节,包括源目的端口,长度和检验和,各占2字节,12字节的伪首部是为了计算检验和临时添加
的。
- TCP报文段格式
- 序号:表示TCP报文段的数据部分的第一个字节的编号
- 确认号:期望收到下一个报文段的序号
- 数据偏移:报文段中数据部分距离首部第一个字节的偏移量,实际就是首部的长度
- 确认ACK:当ACK=1时表示确认号字段有效,否则无效。在TCP建立连接后所有的报文段必须把ACK置为1.
- 同步SYN:用来在连接建立时同步序号,当SYN=1,ACK=0时表示这是一个连接请求报文,若对方同意,则报
文段中SYN=1,ACK=1. - 终止FIN:用来释放连接。当FIN=1时,表示报文段的发送方的数据已经发送完毕,并要求释放连接。
- 窗口:接收方告诉发送方自己接收数据的缓冲区还有多少空间可用,希望发送方调制发送方的窗口大小,防止
接收方的接收缓冲区溢出。
三次握手
- 第一步:源主机向目的主机B发送TCP连接请求报文段,其首部SYN(同步字段)=1,ACK(确认字段)=0,并且发送一个同步序号Seq=xx.
- 第二步:目的主机B收到连接请求报文段后,如果同意,则发送确认报文段,报文中ACK=1,SYN=1,表示源主机的请求被接受,并且确认号为xx+1,并为自己选择一个序号yy。
- 第三步:源主机A接收到目的主机发送的确认报文段,会向目的主机也发送一个确认报文段,此时ACK=1,SYN=0,此时确认号为yy+1,序号为xx+1.因为TCP协议规定,SYN置1的报文段消耗一个序号。
- 此后源主机通知应用层,连接已经建立,可以通信了,当源主机向目的主机发送第一个数据报文段时,其序号是XX+1,因为第三步SYN=0,不消耗序号。
- 目的主机收到确认报文段,通知上层应用层,连接已经建立。
- 三次握手的原因:如果服务器接收到一个失效的报文段(也许是因为拥塞导致报文段滞留在网络中),就会发送给客户端一个确认报文段,但是此时客户端收到确认报文,并不会再次发送确认报文段,服务器也就不会收到确认,就认为客户端没有请求连接。
四次挥手
- 第一步:客户端进程发送释放连接报文,并且停止发送数据,释放报文段首部FIN=1,序列号seq=u,即前面发送数据的最后一个字节序号+1,此时客户端进入FIN-WAIT-1(终止等待1)状态,消耗一个序号。
- 第二步:服务器收到释放报文段,发送确认报文段,首部ACK=1,确认号=u+1,并且带上自己的序号seq=v,此时进入
CLOSE-WAIT(关闭等待)状态,这时服务器通知应用层,客户端向服务端的方向释放了,处于半关闭状态,但是服务器若要发送数据,客户端也是可以接受的。客户端收到确认报文段后,就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文段。 - 如果有数据要继续发,服务器将最后的数据发送完,就向客户端发送连接释放报文段,首部是FIN=1,确认号ack=u+1,若服务器在半关闭状态又发送了一些数据,则此时的序号seq=w,此时服务器进入LAST-ACK最后确认)状态。
- 客户端接收到服务端的连接释放报文后,发出确认报文段,首部ACK=1,确认号ack=w+1,序号是seq=u+1。此时客户端进入TIME-WAIT(时间等待)状态。此时TCP连接还没有释放,必须经历2*MSL(最大报文段寿命)的时间后,才进入
CLOSED状态。服务器收到客户端的确认报文段,立即进入CLOSED状态。可以看出,服务器比客户端提前进入CLOSED状态。 - 为什么客户端还要等2倍的MSL时间呢?因为在服务端在LAST-ACK状态需要收到客户端对服务端发送的FIN+ACK报文段的确认,如果没有收到确认,服务端会重新发送,如果客户端不等待的话就不会再次给服务端发送确认,使得服务端一直重发FIN+ACK。而客户端等待的话,就会收到FIN+ACK,然后再一次给服务端发送确认,保证了二者都能顺利进入CLOSED状态。
- 为什么建立连接是三次握手而释放连接是四次握手:因为在建立连接的时候,服务器处于LISTENING状态,当收到建立连接请求SYN报文后,会把ACK和SYN放在一个报文里发送给客户端。而到了释放连接的时候,服务器收到客户端的FIN,表示客户端不在发送数据,但是可以接收数据,而自己未必不发送数据了,所以此时服务端先发送确认报文,然后在有数据要发送的情况下发送数据给客户端,接着发送FIN报文表示自己同意关闭连接,所以服务器的ACK和FIN是分开发送,导致四次握手。
- 如果客户端突然故障怎么办?一般服务器会设置一个保活计时器,时间通常是2小时,如果2小时过了,客户端仍然不发送数据,服务器句每隔75秒发送一个探测报文,连续发送10个仍然没有反应,就认为客户端出了故障或者网络不同了,接着就关闭连接。
tcp连接与断开时,客户端与服务端状态
- CLOSING状态表示: 客户端发送了FIN,但是没有收到服务器的ACK,却收到了服务器的FIN,这种情况发生在服务器发送的ACK丢包的时候,因为网络传输有时会有意外。
- 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 接收到它的连接终止请求的确认。
- TIME_WAIT 两个存在的理由:
- 可靠的实现tcp全双工连接的终止;
- 允许老的重复分节在网络中消逝。
- CLOSED:不在连接状态(这是为方便描述假想的状态,实际不存在)
TCP滑动窗口:启用来实现流量控制。
- 每个TCP连接的一端会有两个滑动窗口,一个是接收窗口,一个是发送窗口,它们是用来暂时存放字节流的。其中发送方的发送窗口的大小通过接收方在TCP报文段中的窗口字段和其他信息来设置。
- 接收窗口按序存放接收到的字节流,如果有未到的字节,则空开其位置,如果在窗口的起始位置连续有字节已到,则窗口向右滑动,直到窗口左边第一个未收到的字节为止。
- 发送窗口的左边部分连续字节收到确认,发送窗口就向右滑动,直到第一个已发送但是未确认的字节。
TCP可靠传输
- TCP使用超时重传机制实现可靠传输。如果一个报文段在超时时间内没有收到确认,那么就重传这个报文段。
- RTTs表示平均往返时间,RTTd表示往返时间偏差,则超时时间RTO=RTTs+4*RTTd。
TCP流量控制
- TCP流量控制是为了控制发送方的发送速率,使得自己能够来得及接收。
- 接收方通过在TCP报文段中窗口字段来控制发送方的发送窗口大小,进而影响发送方的发送速率。
TCP拥塞控制
- 当网络中的某一资源的需求大于其所能够提供的,这时网络性能就降低了,这种情况就叫网络拥塞,为了解决这个问题,就需要拥塞控制。一般包括慢开始,拥塞控制,快重传,快恢复四个控制算法。
TCP连接的建立步骤
- 服务端:
- 服务端创建一个指向本地端口的ServerSocket实例,并且进入监听状态等待客户端的TCP连接请求。
- 服务端通过accpt()方法获取一个客户端的连接,并通过其返回值,创建一个Socket实例。
- 服务端为返回的Socket实例开启一个线程,用这个线程与客户端进行通信。
- 通信完之后,线程调用Socket的close()函数关闭与客户端的连接 。
- 客户端:
- 客户端创建一个指向服务端IP地址和端口的Socket实例,向服务端发送建立连接请求。
- 连接建立之后,客户端开始与服务端通信。
- 通信完之后,客户端调用Socket的close()函数来关闭连接。
- 从浏览器输入URL地址到最后显示内容的过程
- DNS查找对应IP:首先查找浏览器自身缓存的DNS,如果有这个域名的IP映射,并且没有过期,则直接向这个IP地址发送HTTP请求,否则查找本地操作系统的hosts缓存,如果没有过期,就拿出来使用,否则查找本地DNS域名服务器,如果不能解析,就把请求发送给根域名服务器,根域名服务器返回该地址的顶级域名服务器的IP地址,本地DNS服务器联系顶级域名服务器,顶级域名服务器如果无法解析,就查找下一级DNS服务器,把下一级DNS服务器的IP发送给本地DNS服务器,以此类推,直到解析出IP地址。
- HTTP建立连接
- 客户端请求建立TCP连接
- 发送请求行-请求头-空白行-请求体(如果有)
- 服务器处理完请求数据就发送响应行-响应头-空白行-响应体
- 一般服务端在发送完数据后,会关闭TCP连接,但是如果服务器或者客户端在请求头里加入Connection:keep-alive
信息,那么TCP就不会关闭,这样就可以减少建立连接所需要的时间,节约了资源。 - 浏览器收到HTML文件时,如果遇到frame,img,link,js都会重新发送http请求。
HTTPS协议
- HTTPS协议是对HTTP报文内容的加密协议,其通过在HTTP报文与TCP报文之间使用SSL或者TLS握手对HTTP报文进行加密。虽然提供了安全保证,但是带来了时间上的损失。
HTTP状态码
状态码 | 类别 | 原因 |
---|---|---|
1xx | 信息性状态码 | 接收请求正在处理 |
2xx | 成功状态码 | 请求处理完毕 |
3xx | 重定向状态码 | 需要附加操作才能完成请求 |
4xx | 客户端错误状态码 | 服务器无法处理请求 |
5xx | 服务端错误状态码 | 服务器处理请求错误 |
创建的状态码
状态码 | 200 | 204 | 206 | 301 | 302 | 303 | 304 | 400 | 401 | 403 | 404 | 500 | 503 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
英文描述 | OK | No Content | Particail Content | Moved Permanently | Found | See Other | Not Modifield | Bad Request | Unauthorized | Forbidden | Not Found | Internal Server Error | Service Unavailable |
中文描述 | 请求已正常处理 | 请求处理完成,但是没有任何资源返回 | 部分资源 | 请求资源的URI已经更新,永久性重定向 | 资源 | URI已经临时更新,临时性重定向资源 | URI已经更新,是否按临时的URL访问 | 资源已经找到,但未符合请求条件 | 服务器无法理解客户端发送的请求 | 发送的请求需要HTTP认证(即需要响应的用户名和密码) | 客户端禁止访问该资源(没有权限) | 服务器上没有找到客户端请求的资源 | 服务器内部资源出故障了 |
URL与URI的区别
- URL:统一资源定位符,他是Internet上的资源地址,可以用于指定资源的位置和访问资源的协议,如http,https, ftp, mailto 等协议。其包含:
- 访问资源的协议
- 服务器位置(IP地址或者域名)
- 服务器的端口号(可选,因为一般有些应用协议有默认的端口号)
- 资源在服务器目录结构中的位置
- 片段标识符(可选)
-URI:统一资源标识符,标识物理或者逻辑资源的字符序列,不涉及访问协议,是一个更简单和可扩展的标识资源的方
法,且URL是URI的子集。
HTTP协议与TCP,IP协议的关系:
- HTTP协议属于应用层的协议,而TCP属于传输层的协议,其解决的是数据包的可靠传输,使得
接收包与发送包的顺序一致。IP属于网络层的协议,其解决的是网络路由和寻址问题。
如何理解HTTP协议的无状态:
- HTTP协议是无状态的指的是协议对于事务处理是没有记忆能力的,服务器不知道客户端是什么状
态,也就是打开服务器上的一个资源与上一次打开这个服务器的资源是没有任何联系的,HTTP是面向连接的无状态协议,无状态并不代表HTTP不能保持TCP的连接。
什么HTTP长连接,短连接
- 在HTTP/1.0版本中,默认的是短连接,也就是说客户端每次请求一次HTTP操作,就建立一次连接,
请求完毕就断开连接,即使下一次访问同样的资源。而从HTTP/1.1版本开始通过在响应头中加入Connection:keep-alive字段来引入长连接,默认使用 长连接,也就是说当客户端打开一个服务端的资源,TCP连接 并不会关闭,如果客户端继续访问这个服务器,就会继续使用已经建立的连接。但是该长连接并不会永久的,而是有一个保持时间,这需要在服务器中设定。HTTP协议的长短连接实际上是TCP协议的长短连接。
Session与Cookie
- Session和Cookie是跟踪Web程序常用的技术。Cookie通过在客户端记录信息确定用户身份,而Seesion通过在服务端记录信息确定用户身份。一个用户的所有请求操作都属于同一个会话,而Web程序使用的HTTP协议,HTTP协议是无状态的协议,一旦数据交换完毕就要断开连接,再次交换数据时就需要重新建立连接,这就意味着服务器无法从连接上跟
踪会话,所以就用Cookie机制。Cookie实际上就是一小段文本信息,客户端第一次请求时,服务器就会给客户端返回一个Cookie,这个Cookie就代表当前的客户端,客户端收到这个Cookie后保存在浏览器里,下次请求时就带上这个Cookie,以此证明自己的身份。