带你一文看懂--应用层、传输层的协议，HTTP协议及实现，UDP和TCP的报文格式以及为什么3次握手和4次挥手

网络基础：TCP/IP四层模型中的典型协议--理解网络通信的流程原理

应用层协议：负责应用程序之间的数据沟通

网络版计算器：客户端向服务端传递两个数字以及一个运算符，服务端收到数据进行解析得到数字与运算符，然后进行运算，最终将结果返回给客户端

int num1=10; int num2=20; char op="+";

客户端需要将多个数据对象进行格式组织，然后通过网络数据传输，传递给服务端

方案一：将3个数据对象组成成为一个字符串：“10；20+”

方案二：将3个数据对象在内存中进行二进制排列：定义9个字节空间，前4个放第一个数字，中间4个放第二个数字，最后一个字节。

如何快速的在内存中将多个数据对象按照指定格式进行组织排布？---解决方案结构体（方案二）

typedef struct _tmp_t{

int num1;

int num2;

char op;

}tmp_t;

结构体成员变量赋值的过程就是数据对象在内存中进行二进制数据组织的过程、使用结构体进行数据对象的二进制结构化组织，进行数据传输/可持久化数据存储

序列化：将数据对象按照指定协议进行组织成可持久化存储/数据传输的二进制数据串

反序列化：将持久化存储/数据传输的二进制数据串按照指定协议解析出各个数据对象

常见的数据序列化方式有很多：json序列化；protobuf序列化

HTTP协议：超文本传输协议---http协议有一个很好的优点：http协议给程序员留有一定的自定制空间。

网址：统一资源定位符（定位网络中唯一的一份资源）--URL

例如：https://username:password@www.baidu.com/s?wd=c%2B%2Brsv_spt=1#ch

https：协议方案名称，加密的http协议。

username:password：本次访问服务器的用户认证信息，安全性太低，现在不用了。

www.baidu.com：80：域名--经过域名解析--对应服务器的IP地址，80端口-默认

/s：请求的资源在服务器上的路径（相对路径）--不一定是实体资源

wd=c%2B%2Brsv_spt=1：查询字符串：当前客户端提交给服务端的数据，由一个个 key=value形式的键值对组成，键值对之间以&符号间隔

#ch:片段标识符 --指向html中的一个标签

为什么用户提交给服务器的查询字符串中的val需要进行URL编码？
因为URL中有很多的特殊字符具有特殊函数含义，若用户提交的数据中也包含相同的特殊字符就会造成歧义，因此需要对val进行URL编码操作。

URL编码：将特殊字符的每一个字节都转换成为16进制数字的字符，例如：+->0x2b;万一要是用户本身提交的数据就有2b，也会造成歧义；因此对每一个字节进行转换之后，需要在前边加上%表示紧跟其后的两个字符经过了URL编码+->%2b

URL解码：得到查询字符串后，在val中遇到%，则认为紧跟其后的两个字符需要解码--将2个字符转换为数字%2b->2 11;第一个数字2=0010左移4位或者第一个数字乘以16+后边的数字：2*16+11=43

fiddler工具：浏览器的抓包工具，抓取浏览器与服务器之间的通信数据

HTTP协议格式：就是协议的实现--就是http协议的数据结构

首行：

请求首行：包含三大信息，以空格进行间隔，并且以\r\n作为结尾；

请求方法： URL协议版本。不同的请求方法具有不同的主要负责功能

GET:请求获取一个资源，并要求服务器返回实体数据

HEAD：请求获取一个资源，但是并不要求服务器返回实体数据

GET/POST：get也能向服务器提交数据，但是提交的数据是在URL的查询字符串中（get无正文）/而POST提交的数据在正文中

get提交数据不太安全，并且URL长度有限制，早期1K，现在很多4K/8K

URL：请求的资源路径以及提交的查询字符串

协议版本：HTTP/1.1 0.9/1.0/1.1/2

0.9:默认只支持GET请求方法，并且是短连接，http在传输层使用tcp协议，短链接指的是发送一个请求，得到响应后关闭连接

1.0：支持了GET/HEAD/POST请求方法，并且支持长连接

1.1：支持了更多的请求方法，新增更多特性，默认支持长连接，且实现管线化传输等等

2.以前都是客户端向服务器发送请求，2.0支持服务端向客户端主动发送信息。

响应首行：包含三大信息，以空格进行间隔，以\r\n作为结尾；

协议版本：响应状态码状态码描述\r\n

状态响应码：向客户端反映本次请求的处理结果状态--包含五大种类：1xx/2xx/3xx/4xx/5xx

1xx：一些描述信息

2xx:本次请求正确处理完毕 200--请求成功

3xx：重定向，本次请求的资源可能移动到其他位置，请客户端重新请求新的位置 301-永久/302-临时/303--查看其他

4xx:客户端错误：400/404

5xx:服务端错误：500/502/504

状态码描述：对于本次状态码的描述信息

头部：一个个key：val形式的键值对，键值对之间以\r\n作为间隔（每个键值对以\r\n作为结尾）

connection：描述当前连接是否是长连接close/keep-alive

Content-Length（重要）：描述当前正文有多长；（通过这个描述信息可以告诉对端本次请求应该接收多长的数据）

first\r\nkey:val\r\nkey:val\r\nkey:val\r\n\r\ncontent

first\r\nkey:val\r\nkey:val\r\nkey:val\r\n\r\n--通过头部中的content-length就知道正文应该接收多长。

content-type（重要）：描述了正文的类型--告诉对方应该如何处理正文 test/html

Accept**：告诉对端自己能够接收什么样的数据

Referer：告诉服务器，本次请求是从哪个网页点击请求过来的

Transfer-Encoding:chunked 正文的分块传输--将正文分为多块传输，每块在发送前先告诉对方这块数据有多长；0\r\n\r\n表示分块结束，常用于服务端本身不确定自己要响应的数据有多长的时候。

Location：http：//123.207.58.25/ 搭配3xx状态码使用；通过描述的地址信息告诉客户端重新请求指定的这个地址

Cookie/Set-Cookie：http协议是一个无状态协议

网上购物：http是一个短连接；买一个硬盘，需要登陆一次；买个键盘，又要登陆一次；

服务端为每一个登陆的客户端在服务端主机上创建一个session(会话)；会话中描述了客户端的各种信息；将session保存在数据库中，然后通过Set-Cookie将sessionid以及重要的信息返回客户端；客户端会将其中的信息保存在cookie文件中；下一次请求服务端的时候，会自动从cookie文件中读取出信息，通过Cookie传递给服务端。

Cookie与session有什么区别：

Session是服务端为每一个客户端单独创建的会话，保存在服务端，其中有客户端的认证信息...

Cookie是服务端通过Set-Cookie响应给客户端的信息，保存在客户端，下次请求服务器的时候会携带有Cookie信息

空行：\r\n--间隔头部与正文

头部中最后一个头部信息也是以\r\n作为结尾的；空行的重要性在于判断是否接收了完整的http头部信息

first_line\r\nkey:val\r\neky:val\r\n......key:val\r\n\r\nconnect

通常接收http数据时的流程：

1.接收完整的http头部--接收数据知道遇到\r\n\r\n的时候，认为头部到此结束；

2.解析头部，根据头部中的Connect-Length决定，正文应该接收多长；接收相应长度的正文

正文：客户端提交给服务端的数据/服务端响应给客户端的数据

编写一个简单的http服务器：http协议是应用层协议，在传输层使用的是TCP协议

1.搭建TCP服务器

2.等待连接到来，接收http数据（应用层数据）

（1）接收http头部数据

（2）解析头部（请求方法+URL（资源路径+查询字符串）+协议版本+各个头部键值对）

（3）根据头部中的Connect-Length接收正文

3.针对客户端的请求进行业务功能处理，处理完毕之后组织http响应数据，发送给客户端

（1）业务处理（跟具体的业务相关）

（2）根据http响应格式组织响应数据（首行（协议版本+状态描述码）+描述+头部+正文）

搭建一个http服务器，收到请求之后打印出来，然后组织一个响应hello world给客户端。

直接上代码：

 1 #include <iostream>                                                            2 #include <stdlib.h>3 #include "tcpsocket.hpp"4 #include <sstream>5 6 7 //使用封装的Tcpsocket类实例化对象实现tcp服务端程序8 9 int main(int argc,char *argv[]){10   if(argc!=3){//表示参数的个数，看输入的参数是否为311     printf("em: ./tcp_srv 192.168.122.132 9000\n");12     return -1;13   }14   std::string ip=argv[1];15   uint16_t port =atoi(argv[2]);//stoi将字符串转换为数字16 17   TcpSocket lst_sock;18   CHECK_RET(lst_sock.Socket());//创建套接字19   CHECK_RET(lst_sock.Bind(ip,port));//绑定地址信息20   CHECK_RET(lst_sock.Listen());//开始监听21   while(1){22     TcpSocket cli_sock;23 //    std::string cli_ip;24   //  uint16_t cli_port;25     //accept类成员函数，使用的私有成员_sockfd就是lst_sock的私有成员26     cli_sock取地址传入，目的是为了获取accept接口返回的通信套接字描述符27     bool ret=lst_sock.Accept(&cli_sock);//获取新套接字28     if(ret==false){29       //获取新连接失败，可以重新继续获取下一个30       continue;31     }32     std::string http_req;33     cli_sock.Recv(&http_req);34     printf("req:[%s]\n",http_req.c_str());35 36     //响应--首行(版本/状态码/描述)--头部(Content-Length)-空行-正文37     std::string body="<html><body><h1>Hello World</h1></body></html>";38     std::string blank="\r\n";39     std::stringstream header;40     header<<"Content-Length: "<<body.size()<<"\r\n";41     std::string first_line ="HTTP/1.1 200 OK\r\n";42 43     cli_sock.Send(first_line);44     cli_sock.Send(header.str());45     cli_sock.Send(blank);46     cli_sock.Send(body);47     cli_sock.Close();48   }49   lst_sock.Close();50   return 0;51 }

结果如下：

std::string first_line ="HTTP/1.1 302 Found\r\n";//将上述代码中41行代码换为：302重定向,指定跳转到百度网页

应用层：负责应用程序之间的数据沟通---自定制协议/HTTP协议

1.HTTPS协议：其实就是加密后的HTTP协议： http：443 /http：80

2.https到底是如何进行加密传输的：通过ssl加密实现--非对称加密算法/对称加密算法+签名证书

数据直接在网络中传输，很容易被劫持修改，有很大的安全隐患---对传输过程进行加密

对称加密算法：如何加密就如何解密--解密算法和解密算法一样

优点：加密解密效率较高；缺点：易破解，使用时间稍长就被中间劫持，根据规律破解。

非对称加密算法：加密和解密算法方法不同---服务端生成一个公钥和私钥

公钥和私钥：通过加密算法--RSA算法，得到一对密钥（两串数据），公钥用于对数据加密，私钥用于对加密后的数据进行解密。因为加密和解密方式不同，难破解，就算中间公钥被劫持，客户端使用公钥加密后的数据只能用私钥解密。

优点：安全性高，难破解缺点：解密效率低

3.将非对称加密和对称加密结合起来：将客户端与服务端进行动态协商对称加密算法过程使用非对称加密保护起来；然后使用协商后的对称加密算法对数据通信过程进行加密；保证了安全也保证了数据。

若中间黑客劫持公钥数据，然后将自己的公钥发送给客户端。因此公钥传输也存在安全隐患：对方的身份问题。--签名证书（CA）

签名证书（CA）:进行身份验证，并且传输公钥信息（注意）

公司生成了一对密钥之后，拿着密钥去权威机构掏钱颁发生成一个签名证书，证书中包含：公钥信息，权威机构信息，当前公司机构的信息，有效时间...

4.ssl加密过程：在通信的时候，连接建立成功之后，服务端会先将证书发送给客户端，客户端根据证书中的机构信息，进行身份验证；

若身份不通过，则直接断开连接（也可设置是否信任这个机构）；

若身份验证通过，使用证书中的公钥加密对称算法的协商过程，最终使用协商成功的对称加密算法对通信加密。

传输层：负责应用程序之间的数据传输:UDP/TCP

UDP：报文格式如下：

16位源端口/16位目的端口：描述数据从哪个进程发送到哪个进程--负责实现应用

16位数据报长度：包含UDP报文头部在内的整体报文长度--存储的最大数字是65535

16位校验和：二进制反码求和算法，用于校验接收到的数据和发送的数据是否一致

发送方在发送数据前，检验和为0，从完整报文的第0个字节开始，每个字节进行取反相加，超过16位的部分取出来，再次跟第16位进行相加，最终得到一个校验和填充到协议字段中，接收方接收到是数据之后，再次从完整报文第0个字节开始，每个字节就取反相加，最终得到一个值，若为0，数据一致，否则数据不一致。

无连接：不需要建立连接，只要知道对方地址，就可直接通信

不可靠：通信过程中，并不保证数据安全可靠及有序的到达对端。

数据报传输：无连接的，不可靠的，最大传输长度限制的一种传输方式

实现：有最大传输长度限制：UDP报头部中有一个数据报长度字段，最大数字65535，限制了一个完整UDP报文的长度不能超过64K

对上层程序编写人员的影响：

影响：1.若sendto传输的数据（应用层的原始数据）大小大于64K-8（UDP报文头部长度8个字节），传输报错。因此，若数据过长，需要程序员在应用层手动将大数据分割成小数据段（步大于64k-8）进行sendto发送

2.UDP并不保证数据有序到达，在上层程序员数据分包之后，考虑在应用层实现各个数据段的包序管理

3.UDP报文整条收发；因此UDP使用recvfrom获取数据时，给的buffer足够大，防止出现数据过长给的buffer不够而报错，接收失败的情况。因为UDP报文头部定义了报文长度，因此sendto发送数据时，数据一到发送缓冲区就会直接封装UDP报文头部，然后发送数据，

TCP：面向连接，可靠传输，面向字节流

TCP报文格式：--协议实现

16位源端口/16位目的端口：负责应用程序之间的数据传输

32位序号/32位确认序号：实现确认应答机制，以及进行包序管理

hlen--4位头部长度：表示TCP头部多长；TCP头部是不定长数据，主要取决于选项数据的大小，以4字节为单位，TCP头部最小20字节，最大60字节（其中选项数据占0~40字节）

6位保留位：用于以后扩展

6位标志位：URG紧急指针/ACK确认号/PSH是否读取数据/RST复位报文段/SYN同步报文段/FIN结束报文段

16位窗口大小：实现滑动窗口机制，进行流量控制

16位校验和：二进制反码求和算法，校验数据接收与发送的一致性

16位紧急指针：标识哪些数据是紧急数据（带外数据）

0~40字节的选项数据：通常用于协商一些信息。

面向连接：TCP协议中的连接管理（连接建立成功才能通信）

为什么是3此握手和4次挥手？（两次不安全，四次没必要）

TCP是双向通信，必须确保双方都具有数据收发的能力；假设客户端发送连接请求之后，直接退出了，因此都要给对方发送SYN请求

发送FIN，只是表示不在给对方发送数据，不代表不再接受数据，因此被动关闭方对FIN确认回复之后，依然还可能要发送数据，主动关闭方还有可能继续接收数据。因此被动关闭方不能将ACK与FIN合成一个进行发送（中间依然有可能数据通信）

握手失败了后服务端如何处理？

握手是三次，若服务端回复ACK+SYN后，迟迟无法得到回复，则服务端会发送RST重置连接报文，然后销毁socket。

SYN泛洪攻击：恶意主机，不断发送SYN请求给服务器，但是不进行最后一次ACK回复

主动关闭方的TIME_WAIT有什么用？

TIME_WAIT：--保护主动关闭方（客户端），避免立即使用相同地址信息通信

1.假如没有TIME_WAIT状态主动关闭方直接释放socket，意味着端口和地址可立即重新使用。

2.若最后一次主动关闭方发送ACK丢失，被动方关闭，等待最后一个ACK超时后就会重传FIN包

3.如果主动方关闭，无TIME_WAIT状态，直接释放资源，主机立即使用了刚才的套接字的端口和地址信息重新启动程序。

都属于上一次连接没有全部清理完毕，导致对新的连接造成影响，因此主动关闭方必须等待一段时间：2个MSL--2个报文的最大生存周期，能够处理被动关闭方有可能重传的FIN包，并且等待本次通信的所有数据都消失在网络中，避免对后续连接造成影响

一个主机上出现了大量的CLOSE_WAIT是什么原因？

证明自己的代码有问题，连接断开后，没有关闭套接字释放资源。

CLOSE_WAIT状态，被动关闭方接收到FIN进行回复之后的状态，等待用户确认关闭套接字不在给对方发送数据。

一个主机上出现了大量的TIME_WAIT是什么原因？

TIME_WAIT是主动关闭方才有的状态，常出现于爬虫服务器，大量的主动关闭了连接，地址重用/缩短TIME_WAIT等待时间。

可靠传输：保证数据能够安全有序到达对端（只要不是网络断开一定保证数据到达）

实现：面向连接/确认应答机制/超时重传机制/序号/确认序号/检验和

避免丢包：滑动窗口机制/拥塞机制

提高性能：快速重传机制/延迟应答机制/捎带应答机制

确认应答机制：对于发送的每一条数据，都要求接收方进行确认回复

超时重传机制：在指定时间内没有收到确认回复，则认为数据丢失，对之前的数据进行重传

协议字段中的序号/确认序号：进行包序管理，并且实现确认应答机制

确认序号：就是告诉发送方，这个确认序号以前的数据已经收到了。可避免因为ack确认回复的丢失而导致重传，第一条数据丢失，就算收到第二条也不会回复，每一条回复都表示之前数据收到。

协议字段中的校验和：校验数据是否一致，不一致则要求重传。哪一条数据不一致，则回复这条数据的起始序号。例如1~1024数据不一致，回复序号1，要求对方重传1起始数据

滑动窗口机制：通过协议字段中的窗口大小实现数据连续发送及流量控制-通过窗口大小告诉对象最多发送多少数据，避免因为发送数据过多，接收缓冲区满溢导致的丢包。

在三次握手的时候，通信双方会通过选项数据协商一个信息：MSS--最大数据段大小（应用层的原始数据大小）；TCP发送数据时，会从发送缓冲区取出不大于MSS大小的数据封装TCP头部进行发送

窗口大小通常不大于接收方，接收缓冲区剩余空间大小

（1）窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).
（2）发送前四个段的时候, 不需要等待任何ACK, 直接发送;

（3）收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
（4）操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
（5）窗口越大, 则网络的吞吐率就越高;

发送窗口：前沿减去后沿就是接收方告知的窗口大小

后沿：发送数据的起始序号--后沿的移动取决于是否收到了确认回复

前沿：能够发送的数据结束序号--前沿的移动取决于接收方告知的窗口大小

接收窗口：前沿减去后沿不大于接收缓冲区中剩余空间大小

后沿：接收数据的起始序号--后沿的移动取决于是否收到的起始序列的数据

前沿：接收数据的结束序号--前沿的移动取决于缓冲区剩余空间大小（改变：数据取出/缓冲区重新调整大小）

滑动窗口中出现丢包，如何重传？

1.数据包抵达，ACK丢了，可通过后续ACK确认。

2.数据包直接丢了，快速重传机制

快速重传机制：发送方连续发送多条数据时，若接收方首先接收到第二条数据，则有理由认为第一条可能丢失，因此向发送端连续发送第三条同样数据重传请求，发送方接到3次连续请求，则重传这条数据。为什么是三次？

有可能前边数据延迟，而并非丢失，三条重传请求之间可有一个缓冲时间，这个时间内若收到第一条数据，三次重传请求没发送完，则发送端就不用重传了。

重传存在三种协议：停等协议/选择重传协议/回退n步协议

停等协议：收到一条回复才会发送第二条数据---适用于网络状况特别差的场景。

选择重传协议：哪条丢了重传哪条。

回退n步协议：从丢失的数据开始，往后的数据都需要重传一遍。

拥塞机制：滑动窗口实现一次连续发送多条数据，一开始在网络不明情况下可能会造成因为网络状况不好导致发的越多，丢的越多。

在发送数据时，进行网络探测，查看网络是否能够支持数据的连续快速传输

实现原理：慢启动，快增长。（先发少量数据，探探路，摸清网络拥堵状态，再决定多大速度传输数据）

发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;为了使不增长那么快，引入慢启动阈值，达到一定程度线性增长。

延迟应答机制：（提高效率）

接收方若接收到数据之后立即回复，则窗口大小会变小，传输吞吐率会降低，因此接收方使用延迟应答机制，延迟一段时间再处理，这段时间内，有可能数据被用户取出，保证传输吞吐率。

捎带应答机制：（提高效率）

每一条确认回复，都是一个确认回复序号，为了确认回复，必须组织TCP数据报发送给对端，会造成大量空包传输。若即将发送一条数据给对端，则可以在这条数据包头中对上一个数据确认回复，节省一个空报头传输。

面向字节流：提供的是可靠的，有序的，基于连接的字节流传输

字节流传输：数据在缓冲区中堆积，比较灵活，以字节为单位进行存放/取出--传输比较灵活

发送缓冲区中有很多数据，TCP会根据MSS取出合适大小数据传输

接收缓冲区中有很多数据，TCP可灵活的以用户需要的大小向上交付。

但是这种数据在缓冲区中堆积有一个缺陷:TCP粘包--将多条数据当作一条数据处理

粘包的本质原因：TCP在传输层对数据边界不敏感，造成粘包问题。

粘包的解决方案：程序员在应用层进行数据的边界管理

1.特殊字符间隔--每条数据结尾有个特殊字符，数据中的特殊字符需要进行转义

2.数据定长--每次只发送/接收指定长度数据，数据短会造成资源浪费

3.在应用头中定义数据长度字段--先按照指定长度将头部获取，根据头部中的长度，取出指定长度数据。

典型的：HTTP先用特殊字符间隔头部，头部中定义正文长度；UDP头部定长，在头部中定义数据长度

UDP根本不会产生粘包--UDP数据是整条收发的。

带你一文看懂--应用层、传输层的协议，HTTP协议及实现，UDP和TCP的报文格式以及为什么3次握手和4次挥手相关推荐

带你一文看懂数字乡村怎么建
引言新一代信息化的大背景下,数字乡村.智慧城市.数字中国的概念,近几年被频繁提及.今年在疫情防控的环境下,农产品电商.在线助农.农业直播等互联网农业新业态不断涌现.近日,中央网信办等七部门联合印发& ...
带你一文看懂 Blockchain + NoSQL数据库
来源 | Tyler Mitchell 译者 | 火火酱,责编 | Carol 图源 | CSDN下载自视觉中国 NoSQL数据库和现代区块链分类账都受益于一套共同的原则.由于其二者平台可以相互补充, ...
干货收藏！Python完整代码带你一文看懂抽样
导读:抽样是从整体样本中通过一定的方法选择一部分样本.抽样是数据处理的基本步骤之一,也是科学实验.质量检验.社会调查普遍采用的一种经济有效的工作和研究方法. 作者:宋天龙来源:大数据DT(ID:bi ...
带你一文看懂MySqL中的事务与索引
子查询:在一条sql语句中嵌入在其他sql语句中的select语句,也叫嵌套查询单行子查询:返回一行记录的子查询. 查询与"成绩优秀" 同学的同班 ...
AMBA总线协议（三）——一文看懂AHB总线所有协议总结（AHB2 AHB-Lite AHB5 ）
AMBA AHB 总线协议介绍请点击以下链接: AMBA总线协议(一)--一文看懂APB总线协议 AMBA总线协议(二)一文看懂AMBA2 AHB2与AMBA3 AHB-Lite总线协议的区别 AMB ...
AMBA总线协议（一）——一文看懂APB总线协议
0.AMBA总线概括 AMBA AHB 总线协议介绍请点击以下链接: AMBA总线协议(二)一文看懂AMBA2 AHB2与AMBA3 AHB-Lite总线协议的区别 AMBA总线协议(三)--一文看懂 ...
无处不在的无线智能——6g 的关键驱动与研究挑战_一文看懂什么是 6G
原标题:一文看懂什么是 6G 2020年行将结束,随着5G网络的建设推进,以及3GPP R16版本的冻结,越来越多的人将关注焦点转移到6G身上. 7月14日,韩国三星电子发布了白皮书<下一代超连 ...
《SOC芯片研究框架》深度科普，发展趋势、技术特点、产业链一文看懂
片上系统SoC(System on Chip),即在一块芯片上集成一整个信息处理系统,简单来说 SoC芯片是在中央处理器CPU的基础上扩展音视频功能和专用接口的超大规模集成电路,是智能设备的" ...
天线巴伦制作和原理_一文看懂巴伦（功能原理、性能参数、基本类型）
原标题:一文看懂巴伦(功能原理.性能参数.基本类型) 巴伦(英语为balun)为一种三端口器件,或者说是一种通过将匹配输入转换为差分输出而实现平衡传输线电路与不平衡传输线电路之间的连接的宽带射频传输线 ...

带你一文看懂--应用层、传输层的协议，HTTP协议及实现，UDP和TCP的报文格式以及为什么3次握手和4次挥手

带你一文看懂--应用层、传输层的协议，HTTP协议及实现，UDP和TCP的报文格式以及为什么3次握手和4次挥手相关推荐

最新文章

热门文章