精华内容
下载资源
问答
  • 应用层协议——原理

    千次阅读 2018-08-30 11:44:34
    应用层协议——原理  应用层协议的实现,只需要写出能够运行在不同的端系统(服务器、手机、电脑等)和通过网络彼此通信的程序。因为网络核心设备(路由器、交换机等,不包括端系统设备)并不在应用层上起作用,只...

    应用层协议——原理

      应用层协议的实现,只需要写出能够运行在不同的端系统(服务器、手机、电脑等)和通过网络彼此通信的程序。因为网络核心设备(路由器、交换机等,不包括端系统设备)并不在应用层上起作用,只在网络层及下面层次起作用,所以不需要为网络核心设备写对应的应用程序,即开发应用程序的时候只需要考虑适配端系统,不需要考虑网络核心设备。

    网络应用程序体系结构

      目前主流的网络应用程序体系结构有两种:客户-服务器体系结构(client-server architecture)对等体系结构(P2P)

    • 客户-服务器体系结构(client-server architecture):客户-服务器体系结构中,至少有一个打开的主机,被称为服务器,它服务来自其他许多称为客户的主机的请求。web应用程序就是一个典型的例子,他总是有至少一个web服务器在运行来响应浏览器的请求。客户-服务器体系结构的一个特征就是服务器具有固定且被知晓的IP地址。
    • 对等体系结构(P2P):P2P体系结构对位于数据中心的专用服务器有最小的(或者没有)依赖。应用程序在间断连接的主机对之间使用直接通信,这些主机对被称为对等方。这些对等方并不为服务提供商所有,为用户控制的台式机、笔记本等所有。因为这种对等方通信不必通过专门的服务器,该体系被称为对等方到对等方

    进程通信

    进程的定义

      在操作系统中,进行通信的实际上是进程(process)而不是程序。一个进程可以被认为是运行在端系统中的一个程序。
      两个不同端系统上的进程,通过跨越计算机网络交换报文而相互通信。发送进程生成并向网络中发送报文;接收进程接收这些报文并可能通过报文发送回去进行响应。
      每对通信进程,我们通常将这两个进程之一标识为客户(client),另一个进程标识为服务器(server)。P2P文件共享的某些应用中,一个进程能够既是客户又是服务器。所以我们可以这样定义客户和服务器进程:在给定的一对进程之间的通信回话场景中,发起通信(即在该会话开始时发起与其他进程的联系)的进程被标识为客户,在会话开始时等待联系的进程是服务器

    进程与计算机网络直接的接口

      进程通过一个称为套接字(socket)的软件接口向网络发送报文和从网络接收报文。套接字是同一台主机内应用层与运输层之间的接口,在发送端的应用程序将报文推进套接字,在该套接字的另一侧,运输层协议负责是该报文进入接收进程的套接字。由于该套接字是建立网络应用程序的可编程接口,因此套接字也称为应用程序和网络之间的应用程序编程接口(Application Programming Interface, API)。应用程序开发者可以控制套接字在应用层的一切,但对改套接字的运输层端几乎没有控制权。开发者对运输层的控制仅限于:①选择运输层协议;②也许能设定几个运输层参数,如最大缓存和最大报文段长度等。一旦开发者选择了一个运输层协议,则应用程序就建立在由该协议提供的运输层服务上。

    进程寻址

      在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组,接收进程需要有一个地址。为了标识改接收进程,需要定义两种信息:①主机的地址;②定义在目的主机中的接收进程的标识符。
      在因特网中,主机由其IP地址(IP address)标识。IP地址是一个32比特的量且能够唯一地标识主机。因为一台主机能够运行多个网络应用,发送报文时,发送进程除了要知道目的地的主机地址外,还需要指定运行在接收主机上的接收进程(接收套接字)。目前比较流行的端口有:Web服务器的80端口、SMTP的25端口等。

    运输服务

    可供应用程序使用的运输服务

      网络中运输层的协议不止一种,开发应用时需要根据需求选择相对应的运输层协议。根据对运输层服务的要求,可以将运输层服务大体分为四类:可靠数据传输吞吐量定时安全性

    可靠数据传输

      有时候数据丢失可能会造成灾难性的后果,所以必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务,就认为提供了可靠数据传输(reliable data transfer)。当运输协议提供这种服务时,发送进程只要将其数据传递进套接字,就可以完全相信该数据将能无差错地到达接收进程。
      此外,某些进程不能提供可靠数据传输,由发送进程发送的某些数据可能不能够到达接收进程。这种运输层协议一般用于多媒体应用,如音频、视频等。这些应用能够承受一定量的数据丢失,却并不致命。

    吞吐量

      在沿着一条网络路径上的两个进程之间的通信会话场景中,可用吞吐量就是发送进程能够向接收进程交付的比特速率。因为其他会话将共享沿着该网络路径的带宽,并且因为这些会话将会到达和离开,该可用吞吐量将随时间波动。这就要求运输层协议能够以某种特定的速率提供确保的可用吞吐量,及吞吐量服务。使用这种服务,该应用程序能够请求r比特/秒的确保吞吐量,并且该运输协议能够确保可用吞吐量总是至少为r比特/秒。

    定时

      运输层协议能提供定时保证,如发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。这种服务队交互式实时应用程序具有很大的吸引力,如网络电话、网络交互游戏等,这些应用为了有效性而要求数据交付有严格的时间限制。

    安全性

      运输协议能够为应用程序提供一种或多种安全性服务。例如,在发送主机中,运输协议能够加密由发送进程传输的所有数据,在接收主机中,运输层协议能够在数据交付给接收进程之前解密这些数据。运输协议还能提供机密性以外的其他安全性服务,包括数据完整性和端点鉴别。

    因特网提供的运输服务

      因特网(更一般的是TCP/IP网络)为应用程序提供两个运输层协议,即UDPTCP。当为因特网创建一个新的应用时,受限要做出的决定是选择UDP还是TCP。每个协议为调用它们的应用程序提供了不同的服务集合。下表为一些应用程序的服务要求。

    应用数据丢失带宽时间敏感
    文件传输不能丢失弹性
    电子邮件不能丢失弹性
    Web文档不能丢失单行(几kbps)
    因特网电话/视频会议容忍丢失音频(几kbps~1Mbps)、视频(10kbps~5Mbps)是,100ms
    存储音频/视频容忍丢失同上是,几秒
    交互式游戏容忍丢视几kbps~10kbps是,100ms
    即时讯息不能丢失弹性是和不是

    TCP服务

      TCP服务模型包括面向连接服务和可靠数据传输服务。当某个应用程序调用TCP作为运输协议时,该应用程序就能获得来自TCP的两种服务。

    • 面向连接的服务:在应用层数据报文开始流动之前,TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提示客户和服务器,使它们为大量分组的到来做好准备。在握手阶段后,一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的,即连接双方的进程可以在此连接上同时进行报文的收发。当应用程序结束报文发送时,必须拆除该连接。
    • 可靠的数据传送服务:通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时,它能够依靠TCP将相同的字节流交付给接收方的套接字,而没有字节的丢失和冗余。

        TCP协议还具有拥塞控制机制,这种服务不一定能为通信进程带来直接好处,但能为因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时,TCP的拥塞控制机制会抑制发送进程(客户或服务器)。

    UDP服务

      UDP是一种不提供不必要服务的轻量级运输协议,它仅提供最小服务。UDP是无连接的,因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务,也就是说,当进程将一个报文发送进UDP套接字时,UDP协议并不保证该报文将到达接收进程。不仅如此,达到接收进程的报文也可能是乱序到达的。
      UDP没有包括拥塞控制机制,所以UDP的发送端可以用它选定的任何速率向其下层(网络层)注入数据。

      下表指出了一些流行的因特网应用所使用的运输协议:

    应用应用层协议支撑的运输协议
    电子邮件SMTP [RFC 5321]TCP
    远程终端访问Telnet [RFC 854]TCP
    WebHTTP [RFC 2616]TCP
    文件传输FTP [RFC 959]TCP
    流式多媒体HTTP (如 YouTube)TCP
    因特网电话SIP [RFC 3261]、RTP [RFC 3550]或专用的(如 Skype)UDP 或 TCP

    因特网运输协议所不提供的服务

      运输层协议服务有可靠数据传输吞吐量定时安全性4个方面的服务。TCP提供了可靠的端到端数据传送,并且TCP在应用层可以很容易地用SSL来加强已提供安全服务。但是,TCP却没有提供吞吐量服务和定时服务,或者说因特网运输协议没有提供这两种服务。

    应用层协议定义

      应用层协议(application-layer protocol)定义了运行在不同端系统上的应用程序进程如何相互传递报文。主要有以下的定义:

    • 交换的报文类型,例如请求报文和响应报文
    • 各种报文类型的语法,如报文中的各个字段及这些字段是如何描述的
    • 字段的语义,即这些字段中包含的信息的含义
    • 一个进程何时以及如何发送报文,对报文进行响应的规则
    展开全文
  • 内核层与应用层通信详解

    万次阅读 2019-07-30 08:41:28
    做驱动开发的肯定会遇到应用层与内核层的通信的问题,首先说内核层与应用层的通信可以大概分为两个方面,第一是应用层向内核层主动传递消息,第二是内核层主动与应用层通信。下面我们将分开来谈两个方面。 我们先来...

    做驱动开发的肯定会遇到应用层与内核层的通信的问题,首先说内核层与应用层的通信可以大概分为两个方面,第一是应用层向内核层主动传递消息,第二是内核层主动与应用层通信。下面我们将分开来谈两个方面。

    我们先来看应用层向内核层传递的方法:

     

     

    BOOL DeviceIoControl ( 
    HANDLE hDevice, // 设备句柄 
    DWORD dwIoControlCode, // IOCTL请求操作代码 
    LPVOID lpInBuffer, // 输入缓冲区地址 
    DWORD nInBufferSize, // 输入缓冲区大小 
    LPVOID lpOutBuffer, // 输出缓冲区地址 
    DWORD nOutBufferSize, // 输出缓冲区大小 
    LPDWORD lpBytesReturned, // 存放返回字节数的指针 
    LPOVERLAPPED lpOverlapped // 用于同步操作的Overlapped结构体指针 
    );

     

     

     

     

     

    DeviceIoControl 这个函数是重点中的重点,几乎所有应用层与内核层的通信与此函数有关,发送控制代码直接到指定的设备驱动程序,使相应的移动设备以执行相应的操作。

    驱动程序可以通过CTL_CODE宏来组合定义一个控制码,并在IRP_MJ_DEVICE_CONTROL的实现中进行控制码的操作。在驱动层irpStack->Parameters.DeviceIoControl.IoControlCode表示了这个控制码。

    说到这里我们不得不提的一个东西就是IRP:

     

    IRP(IO请求包)用于win32和驱动程序通讯,NT内核有一个组件叫做IO管理器。IO管理器负责IRP的分发,驱动程序里创建好设备并且创建好符号链接后,Win32就可以加载驱动了。而要让一个驱动可以处理IRP,必需给驱动添加IRP处理例程。

    添加的方法就是再DriverEntry里面对驱动对象DriverObject操作。该参数是一个指针,指向驱动对象,驱动对象内部有一个MajorFunction数组,该数组的类型是
    NTSTATUS  (*PDRIVER_DISPATCH) (IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp) 。这是一个函数指针,指向每个IRP对于的处理例程。最后就是为所有需要处理的IRP实现对应的例程。

    应用层通过DeviceIoControl 下发指令到内核层,内核层又通过对消息头的判断取出缓冲区的数据进行一系列的操作。

    总得来说来说,有DeviceIoControl的存在,应用层向内核层传递消息就是一件轻松加愉快的事情,我简单的贴一点应用层和内核层的代码,大家可以做参考:

    应用层:

     

    	BOOL bOK = ::DeviceIoControl(hAdapter, IOCTL_PTUSERIO_OPEN_ADAPTER, 
    					pszAdapterName, nBufferLength, NULL, 0, &dwBytesReturn, NULL);
    	// 检查结果
    	if(!bOK)
    	{
    		::CloseHandle(hAdapter);
    		return INVALID_HANDLE_VALUE;
    	}
    	return hAdapter;


     

     

    驱动层:

     

    NTSTATUS DevIoControl(PDEVICE_OBJECT pDeviceObject, PIRP pIrp)
    {
    	// 假设失败
    	NTSTATUS status = STATUS_INVALID_DEVICE_REQUEST;
    
    	// 取得此IRP(pIrp)的I/O堆栈指针
    	PIO_STACK_LOCATION pIrpStack = IoGetCurrentIrpStackLocation(pIrp);
    
    	// 取得I/O控制代码
    	ULONG uIoControlCode = pIrpStack->Parameters.DeviceIoControl.IoControlCode;
    	// 取得I/O缓冲区指针和它的长度
    	PVOID pIoBuffer = pIrp->AssociatedIrp.SystemBuffer;
    	ULONG uInSize = pIrpStack->Parameters.DeviceIoControl.InputBufferLength;
    	ULONG uOutSize = pIrpStack->Parameters.DeviceIoControl.OutputBufferLength;
    	
    
    	ULONG uTransLen = 0;
    
    	DBGPRINT((" DevIoControl... \n"));
    
    	switch(uIoControlCode)
    	{
    	case IOCTL_GET_SHARE_ADD: 

     

    case IOCTL_PTUSERIO_OPEN_ADAPTER: // 根据控制码响应
    		{

    然后驱动就可以从设定好的缓冲区里取数据进行操作。

     

    第二步咱们来聊聊驱动层如何主动向应用层发消息:

    很多情况下,我们需要驱动主动将消息传递给应用层,例如我们写一个网卡驱动,里面过滤传递的数据包,当数据包经过的时候,我们就需要驱动层将消息主动传递给应用层,这时候简单的DeviceIoControl 已经不能实现,那我们可以用共享事件加共享内存的方式来实现。

    原理:通过Ring3创建事件,并将该事件传递给Ring0,同时Ring3创建监控线程,等待Ring0发起事件,此为应用层驱动层共享事件。同时Ring0在内核分配非分页内存,通过DeviceIoControl 传递给Ring3,此为应用层驱动层共享内存。因在DeviceIoControl 中传送Buffer,涉及到内核数据拷贝,大数据量下使用效率很低,故用共享内存的方法。

    应用层代码:

     

    	
        m_hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);     // 创建事件
    
    	// 发事件给ring 0
    	
    	if (0 == DeviceIoControl(hFile, SET_EVENT, &m_hEvent, sizeof(HANDLE), NULL, 0, &uRetBytes,NULL))
    	{
    
    		CloseHandle(hFile);
    		CloseHandle(m_hEvent);
    		printf("SET_EVENT failed\n");
    		return FALSE;
    	}
    
    	// 获得ring 0 的共享内存
    	PVOID add = NULL;
    	if (0 == DeviceIoControl(hFile, IOCTL_GET_SHARE_ADD, NULL, 0, &add, sizeof (PVOID), &uRetBytes,NULL))
    	{
    		CloseHandle(hFile);
    		CloseHandle(m_hEvent);
    		return FALSE;
    	}
    	m_pShareMem = (PVOID)add;
    	return TRUE;

     

    	while (1)
    	{
    		WaitForSingleObject(m_hEvent, INFINITE);
    		{
    
    <span style="white-space:pre">			</span>//等待事件发生
    		}
    	}


    内核层:

     

     

         g_pSysAdd = ExAllocatePool(NonPagedPool, 2048*3);
    	g_pMdl = IoAllocateMdl(g_pSysAdd, 2048*3, FALSE, FALSE, NULL);
    	MmBuildMdlForNonPagedPool(g_pMdl);//建立共享内存

     

     

    UserAddr = MmMapLockedPagesSpecifyCache(g_pMdl, UserMode, NonPagedPool, NULL, FALSE, NormalPagePriority);
    *((PVOID*)pIoBuffer) = UserAddr;//将驱动建立的内存地址传递给应用
    
     memset(g_pSysAdd,0,2048*3);
        RtlCopyMemory(g_pSysAdd, test, (DataOffset - 54)*2);//将需要的数据写入内存
        KeSetEvent((PKEVENT)g_pEvent, 0,FALSE);//通知应用层可以读了
    

    接下来我们就可以在应用层读取里面的数据了,地址就是我们通过DeviceIocontrol得到的地址。
     

     

    展开全文
  • 常见应用层协议

    千次阅读 2019-10-03 11:54:24
    常见应用层协议 1、超文本传输协议 用于传输浏览器使用的普通文本、超文本、音频和视频等数据。 详细情况请看: 2、邮件协议 在互联网中,电子邮件的传送是依靠这些协议完成的。 详细情况请看: 3、文件...

    常见应用层协议

    在这里插入图片描述

    1、超文本传输协议

    用于传输浏览器使用的普通文本、超文本、音频和视频等数据。

    详细情况请看:超文本传输协议HTTP/HTTPS

    2、邮件协议

    在互联网中,电子邮件的传送是依靠这些协议完成的。

    详细情况请看:邮件协议SMTP/POP3/IMAP

    3、文件传输协议

    用来在客户机与服务器之间进行简单文件传输的协议。

    详细情况请看:文件传输协议FTP/TFTP/SSH/SCP

    4、域名解析协议

    万维网上作为域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网。

    详细情况请看:DNS协议详解及报文格式分析

    5、SSH( Secure Shell)

    SSH 为建立在应用层基础上的安全协议。SSH 是目前较可靠,专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。

    将来可能代替其它远程连接方式。

    6、Telnet

    Telnet协议是TCP/IP协议族中的一员,是Internet远程登录服务的标准协议和主要方式。

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

    7、DHCP(Dynamic Host Configuration Protocol)

    DHCP 是一个局域网的网络协议,使用UDP协议工作, 主要有两个用途:给内部网络或网络服务供应商自动分配IP地址,给用户或者内部网络管理员作为对所有计算机作中央管理的手段。

    DHCP有3个端口,其中UDP 67UDP 68为正常的DHCP服务端口,分别作为DHCP Server和DHCP Client的服务端口;UDP 546号端口用于DHCPv6 Client,是为DHCP failover服务,这是需要特别开启的服务,DHCP failover是用来做“双机热备”的。

    8、NTP(Network Time Protoco)

    NTP 是用来使网络中的各个计算机时间同步的一种协议。

    它的用途是把计算机的时钟同步到世界协调时UTC,其精度在局域网内可达0.1ms,在互联网上绝大多数的地方其精度可以达到1-50ms。它可以使计算机对其服务器或时钟源(如石英钟,GPS等等)进行时间同步,它可以提供高精准度的时间校正,而且可以使用加密确认的方式来防止病毒的协议攻击。

    9、SNMP

    SNMP,用于网络管理的协议。SNMP被设计为工作在TCP/IP协议族上,基于TCP/IP协议工作,对网络中支持SNMP协议的设备进行管理。

    所有支持SNMP协议的设备都提供SNMP这个统一界面,使得管理员可以使用统一的操作进行管理,而不必理会设备是什么类型、是哪个厂家生产的。

    展开全文
  • 通常企业级应用系统为提高系统可用性,会采用较昂贵的软硬件设备,如IBM的小型机及至中型机大型机及专有操作系统、Oracle数据库、EMC存储设备等。互联网公司更过的采用PC级服务器、开源的数据库和操作系统,这些廉价...

    高可用的网站架构

    通常企业级应用系统为提高系统可用性,会采用较昂贵的软硬件设备,如IBM的小型机及至中型机大型机及专有操作系统、Oracle数据库、EMC存储设备等。互联网公司更过的采用PC级服务器、开源的数据库和操作系统,这些廉价的设备在节约成本的同时也降低了可用性,特别是服务器硬件设备,低价的商业级服务器一年宕机一次是一个大概率事件,而那些高强度频繁读写的普通硬盘,损坏的概率则要更高一些。
    既然硬件故障是常态,网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能被访问。
    实现上述高可用架构的主要手段是数据和服务的冗余备份及失效转移,一旦某些服务器宕机,就将服务切换到其他可用的服务器上,如果磁盘损坏,则从备份的磁盘读取数据。
    一个典型的网站设计通常遵循如下图所示的基本分层架构模型。

    典型的分层模型是三层,即应用层、服务层、数据层;各层之间具有相对独立性,应用层主要负责具体业务逻辑处理;服务层负责提供可复用的服务;数据层负责数据的存储与访问。中小型网站在具体部署时,通常将应用层和服务层部署在一起,而数据层则另外部署,如下图所示(事实上,这也是网站架构演化的第一步)。

    在复杂的大型网站架构中,划分的粒度会更小、更详细,结构更加复杂,服务器规模更加庞大,但通常还是能够把这些服务器划分到这三层中。如下图所示。

    不同的业务产品会部署在不同的服务器集群上,如某网站的文库、贴吧、百科等属于不同的产品,部署在各自独立的服务器集群上,互不相干。这些产品又会依赖一些共同的复用业务,如注册登录、Session管理服务、账户管理服务等,这些可复用的业务服务也独自部署在独立的服务器集群上。至于数据层,数据库服务、文件服务、缓存服务、搜索服务等数据存储与访问服务都部署在各自独立的服务器集群上。

    大型网站的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。关闭服务或者服务器宕机时产生的影响也不相同,高可用的解决方案也差异甚大。

    位于应用层的服务器通常为了应对高并发的访问请求,会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务,当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时,就将其从集群列表中剔除,并将请求分发到集群中其他可用的服务器上,使整个集群保持可用,从而实现应用高可用。
    位于服务层的服务器情况和应用层的服务层类似,也是通过集群方式实现高可用,只是这些服务器被应用层通过分布式服务调用框架访问,分布式服务调用框架会在应用层客户端程序中实现软件负载均衡,并通过服务注册中心对提供服务的服务器进行心跳检测,发现有服务不可用,立即通知客户端程序修改服务访问列表,剔除不可用的服务器。
    位于数据层的服务器情况比较特殊,数据服务器上存储着数据,为了保证服务器宕机时数据不丢失,数据访问服务不中断,需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份。当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上。
    网站升级的频率一般都非常高,大型网站一周发布一次,中小型网站一天发布几次。每次网站发布都需要关闭服务,重新部署系统,整个过程相当于服务器宕机。因此网站的可用性架构设计不但要考虑实际的硬件故障引起的宕机,还要考虑网站升级发布引起的宕机,而后者更加频繁,不能因为系统可以接受偶尔的停机故障就降低可用性设计的标准。

    高可用的应用

    应用层主要处理网站应用的业务逻辑,因此有时也称作业务逻辑层,应用的一个显著特点是应用的无状态性。
    所谓无状态的应用是指应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行相应的业务逻辑处理,多个服务实例(服务器)之间完全对等,请求提交到任意服务器,处理结果都是完全一样的。

    通过负载均衡进行无状态服务的失效转移

    不保存状态的应用给高可用的架构设计带来了巨大便利,既然服务器不保存请求的状态,那么所有的服务器完全对等,当任意一台或多台服务器宕机,请求提交给集群中其他任意一台可用机器处理,这样对终端用户而言,请求总是能够成功的,整个系统依然可用。对于应用服务器集群,实现这种服务器可用状态实时监测、自动转移失效任务的机制是负载均衡。
    负载均衡,顾名思义,主要使用在业务量和数据量较高的情况下,当单台服务器不足以承担所有的负载压力时,通过负载均衡手段,将流量和数据分摊到一个集群组成的多台服务器上,以提高整体的负载成立能力。目前,不管是开源免费的负载均衡软件还是昂贵的负载均衡硬件,都提供失效转移功能。在网站应用中,当集群中服务是无状态对等时,负载均衡可以起到事实上高可用的作用,如下图所示。

    当Web服务器集群中服务器都可用时,负载均衡服务器会把用户发送的访问请求分发到任意一台服务器上进行处理,而当服务器10.0.0.1宕机时,负载均衡服务器通过心跳监测机制发现该服务器失去响应,就会把他从服务器列表中删除,而将请求发送到其他服务器上,这些服务器是完全一样的,请求在任何一台服务器中处理都不会影响最终的结果。
    由于负载均衡在应用层实际上起到了系统高可用的作用,因此即使某个应用访问量非常少,只用一台服务器提供服务就绰绰有余,但如果需要保证该服务高可用,也必须至少部署两台服务器,使用负载均衡技术构建一个小型的集群。

    应用服务器集群的Session管理

    应用服务器的高可用架构设计主要基于服务无状态这一特性,但是事实上,业务总是有状态的,在交易类的电子商务网站,需要有购物车记录用户的购买信息,用户每次购买请求都是向购物车中增加商品;在社交类的网站中,需要记录用户的当前登录状态、最新发布的消息及好友状态等,用户每次刷新页面都需要更新这些信息。
    Web应用中将这些多次请求修改使用的上下文对象称作会话(Session),单机情况下,Session可由部署在服务器上的Web容器(如JBoss)管理。在使用负载均衡的集群环境中,由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上,所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。
    集群环境下,Session管理主要有以下几种手段。

    Session复制

    Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能,在集群中的几台服务器之间同步Session对象,使得每台服务器上都保存所有用户的Session信息,这样任何一台机器宕机都不会导致Session数据的丢失,而服务器使用的Session时,也只需要在本机获取即可。如下图所示。

    这种方案虽然简单,从本机读取Session信息也很快速,但只能使用在集群规模比较小的情况下。当集群规模较大时,集群服务器间需要大量的通信进行Session复制,占用服务器和网络的大量资源,系统不堪负担。而且由于所有用户的Session信息在每台服务器上都有备份,在大量用户访问的情况下,甚至会出现服务器内存不够Session使用的情况。
    而大型网站的核心应用集群就是数千台服务器,同时在线用户可达千万,因此并不适合这种方案。

    Session绑定

    Session绑定可以利用负载均衡的源地址Hash算法实现,负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上,也可以根据Cookie信息将同一个用户的请求总是分发到同一台服务器上,当然这时负载均衡服务器必须工作在HTTP协议层上。这样在整个会话期间,用户所有的请求都在同一台服务器上处理,即Session绑定在某台特定服务器上,保证Session总能在这台服务器上获取。这种方法又被称作会话黏滞,如下图所示。

    但是Session绑定的方案显然不符合我们对系统高可用的需求,因为一旦某台服务器宕机,那么该机器上的Session也就不复存在了,用户请求切换到其他机器后因为没有Session而无法完成业务处理。因此虽然大部分负载均衡服务器都提供源地址负载均衡算法,但很少有网站利用这个算法进行Session管理。

    利用Cookie记录Session

    早期的企业应用系统使用C/S(客户端/服务端)架构,一种管理Session的方式是将Session记录在客户端,每次请求服务器的时候,将Session放在请求中发送给服务器,服务器处理完请求后再将修改过的Session响应给客户端。
    网站没有客户端,但是可以利用浏览器支持的Cookie记录Session,如下图所示。

    利用Cookie记录Session也有一些缺点,比如受Cookie大小限制,能记录的信息有限;每次请求响应都需要传输Cookie,影响性能;如果用户关闭Cookie,访问就会不正常。但是由于Cookie的简单易用,可用性高,支持应用服务器的线性伸缩,而大部分应用需要记录的Session信息又比较小。因此事实上,许多网站都或多或少的使用Cookie记录Session。

    Session服务器

    那么有没有可用性高、伸缩性好、性能也不错,对信息大小又没有什么限制的服务器集群Session管理方案呢?
    答案就是Session服务器。利用独立部署的Session服务器(集群)统一管理Session,应用服务器每次读写Session时,都访问Session服务器,如下图所示。

    这种解决方案事实上是将应用服务器的状态分离,分为无状态的应用服务器和有状态的Session服务器,然后针对这两种服务器的不同特性分别设计其架构。
    对于有状态的Session服务器,一种比较简单的方法是利用分布式缓存、数据库等,在这些产品的基础上进行包装,使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求,比如利用Session服务集成单点登录(SSO)、用户服务等功能,则需要开发专门的Session服务管理平台。

    高可用的服务

    可复用的服务模块为业务产品提供基础公共服务,大型网站中这些服务通常都独立分布式部署,被具体应用远程调用。可复用的服务和应用一样,也是无状态的服务,因此可以使用类似负载均衡的失效转移策略实现高可用的服务。
    除此之外,具体实践中,还有以下几点高可用的服务策略。

    分级管理

    运维上将服务器进行分级管理,核心应用和服务优先使用更好的硬件,在运维响应速度上也格外迅速。显然,用户及时付款购物比能不能评价商品更重要,所以订单、支付服务比评价服务有更多优先级。
    同时在服务部署上也进行必要的隔离,避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离,而高优先级的服务则需要部署在不同的物理机上,核心服务和数据甚至需要部署在不同地域的数据中心。

    超时设置

    由于服务端宕机、线程死锁等原因,可能导致应用程序对服务端的调用失去响应,进而导致用户请求长时间得不到响应,同时还占用应用程序的资源,不利于及时将返回请求转移到正常的服务器上。
    在应用程序中设置服务调用的超时时间,一旦超时,通信框架就抛出异常,应用程序根据服务调度策略,可选择继续程重试或将请求转移到提供相同服务的其他服务器上。

    异步调用

    应用对服务的调用通过消息队列等异步方式完成,避免一个服务失败导致整个应用请求失败的情况。如提交一个新用户注册请求,应用需要调用三个服务:将用户信息写入数据库,发送账户注册成功邮件,开通对应权限。如果采用同步服务调用,当邮件队列阻塞不能发送邮件时,会导致其他两个服务也无法执行,最终导致用户注册失败。
    如果采用异步调用的方式,应用程序将用户注册信息发送给消息队列服务器后立即返回用户注册成功响应。而记录用户注册信息到数据库、发送用户注册成功邮件、调用用户服务开通权限这三个服务作为消息的消费者任务,分别从消息队列获取用户注册信息异步执行。及时邮件服务队列阻塞,邮件不能成功发送,也不会影响其他服务的执行,用户注册操作可顺利完成,只是晚一点收到注册成功的邮件而已。
    当然不是所有服务调用都可以异步调用,对于获取用户信息这类调用,采用异步方式会延长响应时间,得不偿失。对于那些必须确认服务调用成功才能继续下一步操作的应用不合适使用异步调用。

    服务降级

    在网站访问高峰期,服务可能因为大量的并发调用而性能下降,严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行,需要对服务进行降级。降级有两种手段:拒绝服务及关闭服务。

    • 拒绝服务:拒绝低优先级应用的调用,减少服务调用并发数,确保核心应用正常使用;或者随机拒绝部分请求调用,解决资源,让另一部分请求得以成功,比卖你要死大家一起死的惨剧。貌似Twitter比较喜欢使用随机拒绝请求的策略,经常有用户看到请求失败的故障页面,但是问下身边的人,其他人都正常使用,自己再刷新页面,也好了。
    • 关闭功能:关闭部分不重要的服务,或者服务内部关闭部分不重要的功能,以解约系统开销,为重要的服务和功能让出资源。淘宝在每年的“双十一”促销中就使用这种方法,在系统最繁忙的时段关闭“评价”、“确认收货”等非核心服务,以保证核心交易服务的顺利完成。

    幂等性设计

    应用调用服务失败后,会将调用请求重新发送到其他服务器,但是这个失败可能是虚假的失败。比如服务已经处理成功,但因为网络故障应用没有收到响应,这时应用重新提交请求就导致服务重复调用,如果这个服务是一个转账操作,就会产生严重后果。
    服务重复调用是无法避免的,应用层也不需要关心服务是否真的失败,只要没有收到调用成功的响应,就可以认为调用失败,并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同,即服务具有幂等性。
    有些服务天然具有幂等性,比如将用户性别设置为男性,不管设置多少次,结果都一样。但是对于转账交易等操作,问题就会比较复杂,需要通过交易编号等信息进行服务调用有效性检验,只有有效的操作才能继续执行。

    高可用的数据

    对许多网站而言,数据是其最宝贵的物质资产,硬件可以购买,软件可以重写,但是多年运营积淀下来的各种数据(用户数据、交易数据、商品数据......),代表着历史,已经成为过往,不能再重来,一旦失去,对网站的打击可以说是毁灭性的,因此可以说,保护网站的数据就是保护企业的命脉。
    不同于高可用的应用和服务,由于数据存储服务器上保存的数据不同,当某台服务器宕机的时候,数据访问请求不能任意切换到集群中其他的机器上。
    保证数据存储高可用的手段主要是数据备份和失效转移机制。数据备份是保证数据有多个副本,任意副本的失效都不会导致数据的永久丢失,从而实现数据完全的持久化。而失效转移机制则保证当一个数据副本不可访问时,可以快速切换访问数据的其他副本,保证系统可用。

    • 关于缓存服务的高可用,在实践中争议很大,一种观点认为缓存已经成为网站数据服务的重要组成部分,事实上承担了业务中绝大多数的数据读取访问服务,缓存服务失效可能会导致数据库负载过高而宕机,进而影响整个网站的可用性,因此缓存服务需要实现和数据存储服务同样的高可用。
    • 另一种观点认为,缓存服务不是数据存储服务,缓存服务器宕机引起缓存数据丢失导致服务器负载压力过高应该通过其他手段解决,而不是提高缓存服务本身的高可用。
    • 这里持后一种观点,对于缓存服务器集群中的单机宕机,如果缓存服务器集群规模较大,那么单机宕机引起的缓存数据丢失比例和数据库负载压力变化都较小,对整个系统影响也较小。扩大缓存服务器集群规模的一个简单手段就是整个网站共享同一个分布式缓存集群,单独的应用和产品不需要部署自己的缓存服务器,只需要向共享缓存集群申请缓存资源即可。并且通过逻辑或物理分区的方式将每个应用的缓存部署在多台服务器上,任何一台服务器宕机引起的缓存失效都只影响应用缓存数据的一小部分,不会对应用性能和数据库负载造成太大影响。

    CAP原理

    在讨论高可用数据服务架构之前,必须先讨论的一个话题是,为了保证数据的高可用,网站通常会牺牲另一个也很重要的指标:数据一致性。
    高可用的数据有如下几个层面的含义。

    数据持久性

    保证数据可持久存储,在各种情况下都不会出现数据丢失的问题。为了实现数据持久性,不但在写入数据时需要写入持久性存储,还需要将数据备份一个或多个副本,存放在不同的物理存储设备上,在某个存储故障或灾害发生时,数据不会丢失。

    数据可访问性

    在多份数据副本分别放在不同存储设备的情况下,如果一个数据存储设备损坏,就需要将数据访问切换到另一个数据存储设备上,如果这个过程不能很快完成(终端用户几乎没有感知),或者在完成过程中需要停止终端用户访问数据,那么这段时间数据是不可访问的。

    数据一致性

    在数据有多份副本的情况下,如果网络、服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败。这就会造成各个副本之间的数据不一致,数据内容冲突。实践中,导致数据不一致的情形有很多种,表现形式也多种多样,比如数据更新返回操作失败,事实上数据在存储服务器已经更新失败。
    CAP原理认为,一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(Patition Tolerance,系统具有跨网络分区的伸缩性)这三个条件,如下图所示。

    在大型网站应用中,数据规模总是快速扩张的,因此可伸缩性即分区耐受性必不可少,规模变大以后,机器数量也会变得庞大,这时网络和服务器故障会频繁出现,要想保证应用可用,就必须保证分布式处理系统的高可用性。所以在大型网站中,通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),而在某种程度上放弃一致性(C)。一般说来,数据不一致通常出现在系统并发写操作或者集群状态不稳(故障恢复、集群扩容...)的情况下,应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行某种意义上的补偿和纠错,以避免出现应用系统数据不正确。

    2012年淘宝“双十一”活动期间,在活动第一分钟就涌入了1000万独立用户访问,这种极端的高并发场景对数据处理系统造成了巨大压力,存储系统较弱的数据一致性导致出现部分商品超卖现象(交易成功的商品数超过了商品库存数)。

    CAP原理对于可伸缩的分布式系统设计具有重要意义,在系统设计开发过程中,不恰当的迎合各种需求,企图打造一个完美的产品,可能会使设计进入两难境地,难以为继。

    具体说来,数据一致性又可分为如下几点。

    • 数据强一致:各个副本的数据在物理存储中总是一致的;数据更新操作结果和操作响应总是一致的,即操作响应通知更新失败,那么数据一定没有被更细,而不是处于不确定状态。
    • 数据用户一致:即数据在物理存储中的各个副本的数据可能是不一致的,但是终端用户访问时,通过纠错和校验机制,可以确定一个一致的且正确的数据返回给用户。
    • 数据最终一致:这是数据一致性中较弱的一种,即物理存储的数据可能是不一致的,终端用户访问到的数据可能也是不一致的(同一用户连续访问,结果不同;或者不同用户同时访问,结果不同),但系统经过一段时间(通常是一个比较短的时间段)的自我恢复和修正,数据最终会达到一致。

    因为难以满足数据强一致性,网站通常会综合成本、技术、业务场景等条件,结合应用服务和其他的数据监控与纠错功能,使存储系统达到用户一致,保证最终用户访问数据的正确性。

    数据备份

    数据备份是一种古老而有效的数据保存手段,早期的数据备份手段主要是数据冷备,即定期将数据复制到某种存储介质(磁盘、光盘...)上并物理存档保管,如果系统存储损坏,那么就从冷备的存储设备中恢复数据。

    冷备的优点是简单和廉价,成本和技术难度都较低。缺点是不能保证数据最终一致,由于数据时定期复制,因此备份设备中的数据比系统中的数据陈旧,如果系统数据丢失,那么从上个备份点开始后更新的数据就会永久丢失,不能从备份中恢复。同时也不能保证数据可用性,从冷备存储中恢复数据需要较长的时间,而这段时间无法访问数据,系统也不可用。

    因此,数据冷备作为一种传统的数据保护手段,依然在网站日常运维中使用,同时在网站实时在线业务中,还需要进行数据热备,以提供更好的数据可用性。

    数据热备可分为两种:异步热备方式和同步热备方式。

    异步方式是指多份数据副本的写入操作异步完成,应用程序收到数据服务系统的写操作成功响应时,只写成本了一份,存储系统将会异步的写其他副本(这个过程有可能会失败)。如下图所示。

    在异步写入方式下,存储服务器分为主存储服务器(Master)和从存储服务器(Slave),应用程序正常情况下只连接主存储服务器,数据写入时,由主存储服务器的写操作代理模块将数据写入本机存储系统后立即返回写操作成功响应,然后通过异步线程将写操作数据同步到从存储服务器。

    同步方式是指多份数据副本的写入操作同时完成,即应用程序收到数据服务系统的写成功响应时,多份数据都已经写操作成功。但是当应用程序收到数据写操作失败的响应时,可能有部分副本或者全部副本都已经写成功了(因为网络或者系统故障,无法返回操作成功地响应),如下图所示。

    同步热备具体实现的时候,为了提高性能,在应用程序客户端并发向多个存储服务器同时写入数据,然后等待所有存储服务器都返回操作成功地响应后,再通过应用程序写操作成功。

    这种情况下,存储服务器没有主从之分,完全对等,更便于管理和维护。存储服务客户端在写多份数据的时候,并发操作,这意味着多份数据的总写操作延迟是响应最慢的那台存储服务器的响应延迟,而不是多台存储服务器响应延迟之和。其性能和异步热备方式差不多。

    传统的企业级关系数据库系统几乎都提供了数据实时同步备份的机制。而一开始就为大型网站而设计的各种NoSQL数据库(如HBase)更是将数据备份机制作为产品主要的功能点之一。

    关系数据库热备机制就是通常所说的Master-Slave同步机制。Master-Slave机制不但解决了数据备份问题,还改善了数据库系统的性能,实践中,通常使用读写分离的方法访问Slave和Master数据库,写操作只访问Master数据库,读操作只访问Slave数据库。

    失效转移

    若数据服务器集群中任何一台服务器宕机,那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器,保证数据访问不会失败,这个过程叫做失效转移。

    失效转移操作操作由三部分组成:失效确认、访问转移、数据恢复。

    生效确认

    判断服务器宕机是系统进行失效转移的第一步,系统确认一台服务器是否宕机的手段有两种:心跳检测和应用程序访问失败报告,如下图所示。

    对于应用程序的访问失败报告,控制中心还需要再一次发送心跳检测进行确认,以免错误判断服务器宕机,因为一旦进行数据访问失效转移,就意味着数据存储多份副本不一致,需要进行后续一系列复杂的操作。

    访问转移

    确认某台数据存储服务器宕机后,就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器(几台存储服务器存储的数据完全一样,我们称几台服务器为对等服务器,比如主从结构的存储服务器,其存储的数据完全一样),当其中一台宕机后,应用程序根据配置直接切换到对等服务器上。如果存储是不对等的,那么就需要重新计算路由,选择存储服务器。

    数据恢复

    因为某台服务器宕机,所以数据存储的副本数目会减少,必须将副本的数目恢复到系统设定的值,否则,再有服务器宕机时,就可能出现无法访问转移(所有副本的服务器都宕机了),数据永久丢失的情况。因此系统需要从健康的服务器赋值数据,将数据副本数目恢复到设定值。不影响用户使用。

    展开全文
  • AI:国内外人工智能产业应用图谱应用层/基础层详解 目录 国内外人工智能产业应用图谱 一、应用层 1、AI+医疗 2、AI+家居 3、AI+驾驶 4、AI+零售 5、AI+城市 6、AI+教育 二、基础层 1、算法:...
  • 零、基础理论 网络应用是计算机网络存在的理由,如万维网(包含了web冲浪、搜索和电子商务),以及具有好友列表的即时讯息和...应用层只在端上存在,因此写的时候只需在端上构建。 网络核心最高管到网络层。 SDN:s...
  • 应用层:负责应用程序之间的数据交流 http协议:超文本传输协议 url:统一资源定位符,在网络中唯一定义一份资源。 完整url组成:协议方案名称://用户名:密码@服务器地址:端口号/请求资源路径?查询字符串#片段标识符 ...
  • 物理层、数据链路层、网络层、传输层、会话层、表示层、应用层 TCP/IP分层(4层) 网络接口层、网络层、传输层、应用层 五层协议(5层) 物理层、数据链路层、网络层、传输层、应用层 五层结构的概述 应用层:通过...
  • 传输层协议、应用层协议

    千次阅读 2018-05-10 00:17:10
    传输层协议、应用层协议一、传输层协议1、传输层概述 (1)传输层的作用 IP层提供点到点的连接 传输层提供端到端的连接 (2)传输层的协议 TCP(Transmission Control Protocol)传输控制协议 可靠的、面向...
  • 基于网络层和应用层的DDoS攻击

    千次阅读 2017-11-13 11:54:46
     DDoS攻击是由DoS攻击发展而来的,根据攻击原理和方式的区别,可以把DDoS攻击分为两个阶段,即从传统的基于网络层的DDoS攻击和现阶段较为常见的基于应用层的DDoS攻击,这两类攻击方式各有特点,都对网络的安全造成...
  • 应用层---HTTP协议

    千次阅读 2018-08-27 17:44:30
    应用层 应用层是TCP/IP协议分层的最顶层模型,它的作用是维持好应用程序之间的沟通,维护好特定的协议。 如简单电子邮件传输(SMTP),文件传输协议(FTP),网络远程访问协议(Telnet)等。 应用层协议分为两种,...
  • 15-传输层协议和应用层协议

    千次阅读 2018-04-28 09:49:32
       PS:针对上一篇tcp协议中说到的端到端服务,这里我们再通过传输层协议和应用层协议之间的关系来加深端到端服务的学习和理解。 1. 传输层协议和应用层层协议的关系   在应用层,我们知道有很多协议,比如...
  • 一、基于TCP的应用层协议有:SMTP、TELNET、HTTP、FTP 基于UDP的应用层协议:DNS、TFTP(简单文件传输协议)、RIP(路由选择协议)、DHCP、BOOTP(是DHCP的前身)、IGMP(Internet组管理协议) ...
  • 物联网应用层的关键技术有哪些

    千次阅读 2021-07-19 09:56:09
    应用层包括应用基础设施/中间件和各种物联网应用。 应用层位于物联网三层结构中的最顶层,其功能为“处理”,即通过云计算平台进行信息处理。应用层与最低端的感知层一起,是物联网的显著特征和核心所在,应用层可以对...
  • 常用应用层协议的报文格式

    千次阅读 2019-11-03 16:02:24
    常见应用层协议的报文格式1.常用应用程序的端口号2.HTTP的报文格式 1.常用应用程序的端口号 名称 应用层协议 端口 运输层协议 说明 超文本传输协议 HTTP 80 TCP 域名解析系统 DNS 53 UDP/TCP 长度超过512...
  • 提供的服务可使应用建立和维持会话,并能使会话获得同步。会话使用校验点可使通信会话在通信失效时从校验点继续恢复通信。这种能力对于传送大的文件极为重要。 二、表示 主要作用是为异种机通信提供异种公共...
  • 常见的应用层协议

    千次阅读 2018-09-28 17:13:09
    动态主机配置协议,是一个应用层协议,使用UDP协议工作。当我们将客户主机ip地址设置为动态获取方式时,DHCP服务器就会根据DHCP协议给客户端分配IP,使得客户机能够利用这个IP上网。 DHCP操作 1.寻找DHCP Server ...
  • 数据(Data Layer)相当于区块链四大核心技术中的数据结构,即“区块+链”的结构。从还没有记录交易信息的创世区块起,直到现在仍一直在新添加的区块,构成的链式结构,里面包含了哈希值、随机数、认证交易的时间戳...
  • 应用层常见协议——知识点

    万次阅读 多人点赞 2018-04-18 15:10:09
    这里总结了三种常见的应用层协议:HTTP、FTP、SMTP。供自己复习使用,也供大家参考!一、HTTP协议1、HTTP简介—超文本传输协议(Hypertext transfer protocol)。是一种详细规定了浏览器和万维网(WWW = World Wide Web...
  • 这篇文章主要介绍了网络协议概述:物理层、连接层、网络层、传输层、应用层详解,本文用生活中的邮差与邮局来帮助理解复杂的网络协议,通俗易懂,文风幽默,是少见的好文章,需要的朋友可以参考下 信号的传输总要符合...
  •  应用层(Java Application),包括了Android各种应用程序  应用框架层(Java Frameworks),是Google发布的核心应用所使用的API框架  系统运行库层(User Libraries),包含了手机系统平台必须的C/C++核心库、...
  • 计算机网络应用层协议分析总结

    千次阅读 2018-01-20 15:13:52
    1、应用层协议原理 1.1、网络应用程序体系结构 C/S结构,有一个总是打开的主机称为服务器,它服务于来自许多其他称为客户机的主机请求。客户机主机既可能有时打开,也可能总是打开。C/S结构之下,客户机之间不直接...
  • OSI第七层:应用层功能及介绍

    万次阅读 多人点赞 2019-01-16 18:59:55
    OSI应用层功能:应用层提供各种各样的应用层协议,这些协议嵌入在各种我们使用的应用程序中,为用户与网络之间提供一个打交道的接口。 OSI应用层的作用 当我们第一次学习网络,对网络的概念不会很直观,我们使用...
  • 计算机网络知识点总结-第六章:应用层

    万次阅读 多人点赞 2019-01-28 23:23:08
    应用层协议:每个应用层协议都是为了解决一类应用问题,而解决问题需要通过位于不同主机的多个应用进程之间的通信和协同来完成,应用层的具体内容就是定义这些通信规则 1.域名系统DNS 1.域名系统概述: 域名...
  • 最通俗易懂的网络应用层协议详解

    万次阅读 多人点赞 2017-02-23 17:21:00
    前言其实本文只是讲解从传输层到应用层实现网络消息传递的一个详细流程,至于更底层的网络层和网络接口层,那就不在我的考虑范围内了,事实上那部分机制是不需要你去操心的,除非你想开发操作系统!然后本文打着通俗...
  • TCP/IP协议之应用层

    千次阅读 2020-11-11 22:49:24
    TCP/IP协议之应用层 一.基本概念 **** 应用层协议的实现,只需要写出能够运行在不同的端系统(服务器、手机、电脑等)和通过网络彼此通信的程序。因为网络核心设备(路由器、交换机等,不包括端系统设备)并不在应用...
  • TCP应用层协议

    千次阅读 2019-03-23 17:59:17
    TCP/IP是个协议组,可分为三个层次:网络层、传输层和应用层。 在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。 在传输层中有TCP协议与UDP协议。 在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。 1....
  • 1、硬件,是整个嵌入式系统的根本,如果现在单片机及接口这块很熟悉,并且能用C和汇编语言来编程的话,从嵌入式系统的硬件走起来相对容易,硬件也是驱动的基础,一个优秀的驱动工程师是要能够看懂硬件的电路...
  • 计算机网络——从物理层到应用层

    千次阅读 2018-10-16 21:25:32
    每一都有自己的功能,就像建筑物一样,每一都靠下一支持。 用户接触到的,只是最上面的一,根本没有感觉到下面的。要理解互联网,必须从最下层开始,自下而上理解每一的功能。 如何分层有不同的模型,...
  • 参考:https://zhidao.baidu.com/question/337954440.html 基于TCP的有FTP、Telnet、SMTP、HTTP、POP3与DNS 基于UDP的有TFTP、SNMP与DNS 其中DNS既可以基于TCP,也可以基于UDP。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,123,174
精华内容 849,269
关键字:

应用层

友情链接: TSP_Question.zip