1. 网络编程
网络编程,就是在一定的协议下,实现两台计算机的通信的程序。
2. 通信协议
通过计算机网络可以使多台计算机实现连接,位于同一个网络中的计算机在进行连接和通信时需要遵守一定的规则。
在计算机网络中,这些连接和通信的规则被称为网络通信协议,它对数据的传输格式、传输速率、传输步骤等做了统一规定,通信双方必须同时遵守才能完成数据交换。
3. IP
指互联网协议地址(Internet Protocol Address),俗称IP。它是网络中的计算机设备的唯一编号。假如我们把个人电脑比作一台电话的话,那么IP地址就相当于电话号码。
IP地址分类
- IPv4:是一个32位的二进制数,通常被分为4个字节,表示成a.b.c.d 的形式,例如192.168.65.100 。其中a、b、c、d都是0~255之间的十进制整数,那么最多可以表示42亿个。
- IPv6:由于互联网蓬勃发展,IP地址的需求量愈来愈大,但是网络地址资源有限,IP的分配越发紧张。为了扩大地址空间,拟通过IPv6重新定义地址空间,采用128位地址长度,每16个字节一组,分成8组十六进制数,表示成ABCD:EF01:2345:6789:ABCD:EF01:2345:6789,(可以为全世界的每一粒沙子编上一个网址)。
4. 端口
网络的通信,本质上是两个进程(应用程序)的通信。每台计算机都有很多的进程,那么在网络通信时,如何区分这些进程呢?
如果说IP地址可以唯一标识网络中的设备,那么端口号就可以唯一标识设备中的进程(应用程序)了。
端口号是用两个字节表示的整数,它的取值范围是0 ~ 65535。
其中,0~1023之间的端口号用于一些知名的网络服务和应用,普通的应用程序需要使用1024以上的端口号。
如果端口号被另外一个服务或应用所占用,会导致当前程序启动失败。
利用协议+IP地址+端口号 三元组合,就可以标识网络中的进程,那么进程间的通信就可以利用这个标识与其它进程进行交互。
5. TCP/IP
TCP/IP传输协议,即传输控制/网络协议,也叫作网络通讯协议。它是在网络的使用中的最基本的通信协议。TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定。并且,TCP/IP传输协议是保证网络数据信息及时、完整传输的两个重要的协议。TCP/IP传输协议是严格来说是一个四层的体系结构,应用层、传输层、网络层和数据链路层都包含其中。
TCP/IP协议是Internet最基本的协议,其中应用层的主要协议有Telnet、FTP、SMTP等,是用来接收来自传输层的数据或者按不同应用要求与方式将数据传输至传输层;传输层的主要协议有UDP、TCP,是使用者使用平台和计算机信息网内部数据结合的通道,可以实现数据传输与数据共享;网络层的主要协议有ICMP、IP、IGMP,主要负责网络中数据包的传送等;而网络访问层,也叫网络接口层或数据链路层,主要协议有ARP、RARP,主要功能是提供链路管理错误检测、对不同通信媒介有关信息细节问题进行有效处理等。
TCP/IP协议中的四层分别是应用层、传输层、网络层和链路层。
链路层:定义物理传输通道,通常是对某些网络连接设备的驱动协议,例如针对光纤、网线提供的驱动。
网络层:是整个TCP/IP协议的核心,主要用于将传输的数据进行分组,将分组数据发送到目标计算机或者网络。
运输层:使网络程序进行通信,在进行网络通信时,可以采用TCP协议,也可以采用UDP协议。
应用层:主要负责应用程序的协议,例如HTTP协议、FTP协议等。
6. TCP/UDP区别
TCP:传输控制协议 (Transmission Control Protocol)
UDP:用户数据报协议(User Datagram Protocol)
tcp 和 udp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输,而 udp 则常被用于让广播和细节控制交给应用的通信传输。
两者的区别大致如下:
tcp 面向连接,udp 面向非连接即发送数据前不需要建立链接;
tcp 提供可靠的服务(数据传输),udp 无法保证;
tcp 面向字节流,udp 面向报文;
tcp 数据传输慢,udp 数据传输快;
UDP:由于使用UDP协议消耗资源小,通信效率高,所以通常都会用于音频、视频和普通数据的传输例如视频会议都使用UDP协议,因为这种情况下,即使偶尔丢失一两个数据包,也不会对接收结果产生太大影响。
TCP:完成三次握手,连接建立后,客户端和服务器就可以开始进行数据传输了。由于这种面向连接的特性,TCP协议可以保证传输数据的安全,所以应用十分广泛,例如下载文件、浏览网页等。
7. TCP三次握手
三次握手:TCP协议中,在发送数据的准备阶段,客户端与服务器之间的三次交互,以保证连接的可靠。
第一次握手,客户端向服务器端发出连接请求,等待服务器确认。
第二次握手,服务器端向客户端回送一个响应,通知客户端收到了连接请求。
第三次握手,客户端再次向服务器端发送确认信息,确认连接。
tcp 为什么要三次握手,两次不行吗?为什么?
如果采用两次握手,那么只要服务器发出确认数据包就会建立连接,但由于客户端此时并未响应服务器端的请求,那此时服务器端就会一直在等待客户端,这样服务器端就白白浪费了一定的资源。若采用三次握手,服务器端没有收到来自客户端的再此确认,则就会知道客户端并没有要求建立请求,就不会浪费服务器的资源。
8. TCP四次挥手
● Client状态变化:Fin-Wait-1 -> Fin-Wait-2 -> Time-Wait -> Closed
● Server状态变化:Close-Wait -> Last-Ack -> Closed
具体流程:
1.第一次挥手:客户端发送连接释放报文FIN=1,序号(握手时初始序号 + 发送的字节数据数量 + 1)seq=u,发送完毕后,客户端进入FIN_WAIT_1状态。
2.第二次挥手:服务器发出确认收到报文ACK=1,确认号ack=u+1,序列号(握手时初始序号 + 回复的字节数据)seq=v,发送完毕后,服务器端进入CLOSE_WAIT状态,客户端接收到这个确认包之后,进入FIN_WAIT_2状态。
3.第三次挥手:关闭连接,发送连接释放报文FIN=1,确认号ack=u+1,初始序号seq=w,发送完毕后,服务器端进入LAST_ACK状态,等待来自客户端的最后一个 ACK。
4.第四次挥手: 客户端接收到来自服务器端的关闭请求,发回确认收到报文ACK=1,确认序号ack=u+1,初始序号seq=w+1,客户端进入 TIME_WAIT 状态,等待了某个固定时间(两个最大段生命周期,2MSL,2 Maximum Segment Lifetime)之后,没有收到服务器端的 ACK ,认为服务器端已经正常关闭连接,于是自己也关闭连接,进入 CLOSED 状态。服务器端接收到这个确认包之后,关闭连接,进入 CLOSED 状态。
总结:
Server端可能还有数据没有发送完毕。Client发出连接释放通知,Server确认收到后,Client就进入半关闭状态(只收消息不发消息),Server把未发完的数据发送完毕后,发送连接释放通知,Client确认后就关闭连接。
9. TCP 协议如何来保证传输的可靠性
TCP 提供一种面向连接的、可靠的字节流服务。其中,面向连接意味着两个使用 TCP 的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中,仅有两方进行彼此通信;而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流,TCP 不在字节流中插入记录标识符。
对于可靠性,TCP通过以下方式进行保证:
-
数据包校验
:目的是检测数据在传输过程中的任何变化,若校验出包有错,则丢弃报文段并且不给出响应,这时TCP发送数据端超时后会重发数据; -
对失序数据包重排序
:既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序,然后才交给应用层; -
丢弃重复数据
:对于重复数据,能够丢弃重复数据; -
应答机制
:当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒; -
超时重发
:当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段; -
流量控制
:TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这可以防止较快主机致使较慢主机的缓冲区溢出,这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
10. TCP 粘包
粘包是指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。只有TCP有粘包现象,UDP不会。
产生原因:
当连续发送数据时,由于tcp协议的nagle算法,会将较小的内容拼接成大的内容,一次性发送到服务器端,因此造成粘包当发送内容较大时,由于服务器端的recv(buffer_size)方法中的buffer_size较小,不能一次性完全接收全部内容,因此在下一次请求到达时,接收的内容依然是上一次没有完全接收完的内容,因此造成粘包现象。
解决办法:
在每次使用tcp协议发送数据流时,在开头标记一个数据流长度信息,并固定该报文长度(自定义协议)。在客户端接收数据时先接收该长度字节数据,判断客户端发送数据流长度,并只接收该长度字节数据,就可以实现拆包,完美解决tcp粘包问题。
11. OSI 的七层模型都有哪些?
- 物理层:利用传输介质为数据链路层提供物理连接,实现比特流的透明传输。
- 数据链路层:负责建立和管理节点间的链路。
- 网络层:通过路由选择算法,为报文或分组通过通信子网选择最适当的路径。
- 传输层:向用户提供可靠的端到端的差错和流量控制,保证报文的正确传输。
- 会话层:向两个实体的表示层提供建立和使用连接的方法。
- 表示层:处理用户信息的表示问题,如编码、数据格式转换和加密解密等。
- 应用层:直接向用户提供服务,完成用户希望在网络上完成的各种工作。
12. HTTP/HTTPS
-
Http:Http协议是对客户端和服务器端之间数据之间实现可靠性的传输文字、图片、音频、视频等超文本数据的规范,格式简称为“超文本传输协议”。
-
Https:Http协议运行在TCP之上,明文传输,客户端与服务器端都无法验证对方的身份;Https是身披SSL(Secure Socket Layer)外壳的Http,运行于SSL上,SSL运行于TCP之上,是添加了加密和认证机制的HTTP。
区别:
- http需要拿到ca证书,需要钱的
- 端口不一样,http是80,https443
- http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
- http和https使用的是完全不同的连接方式(http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。)
13. HTTPS工作原理
- 首先HTTP请求服务端生成证书,客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥(RSA加密)等进行校验;
- 客户端如果校验通过后,就根据证书的公钥的有效, 生成随机数,随机数使用公钥进行加密(RSA加密);
- 消息体产生的后,对它的摘要进行MD5(或者SHA1)算法加密,此时就得到了RSA签名;
- 发送给服务端,此时只有服务端(RSA私钥)能解密。
- 解密得到的随机数,再用AES加密,作为密钥(此时的密钥只有客户端和服务端知道)
14. HTTP 请求所经历的步骤
- 建立TCP连接;
- Web浏览器向Web服务器发送请求行:一旦建立了TCP连接,Web浏览器就会向Web服务器发送请求命令。例如:GET /test/hello/1.1。
- Web浏览器发送请求头:浏览器发送其请求命令之后,还要以头信息的形式向Web服务器发送一些别的信息,之后浏览器发送了一空白行来通知服务器,它已经结束了该头信息的发送。
- Web服务器应答:客户机向服务器发出请求后,服务器会客户机回送应答, HTTP/1.1 200 OK ,应答的第一部分是协议的版本号和应答状态码。
- Web服务器发送应答头:正如客户端会随同请求发送关于自身的信息一样,服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
- Web服务器向浏览器发送数据:Web服务器向浏览器发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
- Web服务器关闭TCP连接。
通俗描述:
- 由域名→IP地址 寻找IP地址的过程依次经过了浏览器缓存、系统缓存、hosts文件、路由器缓存、 递归搜索根域名服务器。
- 建立TCP/IP连接(三次握手具体过程)
- 由浏览器发送一个HTTP请求
- 经过路由器的转发,通过服务器的防火墙,该HTTP请求到达了服务器。
- 服务器处理该HTTP请求,返回一个HTML文件。
- 浏览器解析该HTML文件,并且显示在浏览器端。
15. HTTP 协议无状态协议
HTTP 是一个无状态的协议,也就是没有记忆力,这意味着每一次的请求都是独立的,缺少状态意味着如果后续处理需要前面的信息,则它必须要重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就很快。
HTTP 的这种特性有优点也有缺点:
优点:解放了服务器,每一次的请求“点到为止”,不会造成不必要的连接占用。
缺点:每次请求会传输大量重复的内容信息,并且,在请求之间无法实现数据的共享。
解决方案:
使用参数传递机制:将参数拼接在请求的 URL 后面,实现数据的传递(GET方式),例如: /param/list?username=wmyskxz
问题:可以解决数据共享的问题,但是这种方式一不安全,二数据允许传输量只有1kb。
使用 Cookie 技术
使用 Session 技术
16. Cookie
- Cookie实际上是存储在客户端的一小段文本信息。
- 客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie,而客户端浏览器会把Cookie保存起来。
- 当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器,服务器检查该Cookie,以此来辨认用户状态。
- 服务器还可以根据需要修改Cookie的内容。
17. Session
- 会话状态也可以保存在服务器端。
- 客户端请求服务器,如果服务器记录该用户状态,就获取Session来保存状态,这时,如果服务器已经为此客户端创建过session,服务器就按照sessionid把这个session检索出来使用;
- 如果客户端请求不包sessionid,则为此客户端创建一个session并且生成一个与此session相关联的sessionid,并将这个sessionid在本次响应中返回给客户端保存。
- 保存这个sessionid的方式可以采用 cookie机制 ,这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器;
- 若浏览器禁用Cookie的话,可以通过 URL重写机制将sessionid传回服务器。
18. Cookie 和 Session 的区别
实现机制
:Session的实现常常依赖于Cookie机制,通过Cookie机制回传SessionID;
大小限制
:Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制,Session没有大小限制,理论上只与服务器的内存大小有关;
安全性
:Cookie存在安全隐患,通过拦截或本地文件找得到cookie后可以进行攻击,而Session由于保存在服务器端,相对更加安全;
服务器资源消耗
:Session是保存在服务器端上会存在一段时间才会消失,如果session过多会增加服务器的压力。
19. 高并发高解决方案
- 页面静态化。
- CDN缓存:内容分发网络。
- 文件服务器分离
- 数据库集群、分库分表
- 缓存
- 分布式应用
20. GET方法与POST方法的区别
- 区别一: get重点在从服务器上获取资源,post重点在向服务器发送数据;
- 区别二:Get传输的数据量小,因为受URL长度限制,但效率较高;Post可以传输大量数据,所以上传文件时只能用Post方式;
- 区别三:get是不安全的,因为get请求发送数据是在URL上,是可见的,可能会泄露私密信息,如密码等;post是放在请求头部的,是安全的。
21. http版本的对比
HTTP1.0版本的特性:
-
早先1.0的HTTP版本,是一种无状态、无连接的应用层协议。
-
HTTP1.0规定浏览器和服务器保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器处理完成后立即断开TCP连接(无连接),服务器不跟踪每个客户端也不记录过去的请求(无状态)
HTTP1.1版本新特性:
- 默认持久连接节省通信量,只要客户端服务端任意一端没有明确提出断开TCP连接,就一直保持连接,可以发送多次HTTP请求
- 管线化,客户端可以同时发出多个HTTP请求,而不用一个个等待响应。
- 断点续传原理
HTTP2.0版本的特性:
- 二进制分帧(采用二进制格式的编码将其封装)
- 首部压缩(设置了专门的首部压缩设计的HPACK算法)。
- 流量控制(设置了接收某个数据流的多少字节一些流量控制)。
- 多路复用(可以在共享TCP链接的基础上同时发送请求和响应)
- 请求优先级(可以通过优化这些帧的交错和传输顺序进一步优化性能)
- 服务器推送(就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。(重大更新))