soap协议与tcp协议_soap协议请求方法

TCP/IP、Http、Soap三个基本的通讯协议有什么区别？

看到一个说法，比较通俗易懂：

soap协议与tcp协议_soap协议请求方法

soap协议与tcp协议_soap协议请求方法

HTTP就是邮局的协议，他们规定了你的信封要怎么写，要贴多少邮票等。。。。

SOAP就是你们之间交流的协议，负责把你所需要表达的意思写在信纸上，同时也负责让对方能够看得懂你的信。

关soap将信息进行XML的序列化后，再用协议的方式再打包进行传送，传送的方式还是tcp或者udp。做个比喻就好理解了。tcp 和 udp 都是公路，暂且把tcp认为是一般公路，udp高速公路，soap和就都是汽车，那么soap和都可以在tcp和udp上跑。说soap可以通过来传送，实际就是说soap是小轿车，是装轿车的卡车，把soap的信息装到里面，然后再运输，当然走的道路还是tcp或udp。

说soap可以通过协议来传输，这句话不太准确，比较准确第说法是：soap信息可以通过协议包装后通过tcp或udp传输。

WCF 可以不使用soap消息协议吗？直接用TCP协议吗

可以，但是有限制，这个跟宿主形式有关。比如使用Windows 服务就支持 MSMQ协议。

IIS 应该是支持协议最多的宿主。

确定服务的宿主是否支持 TCP 后，可以使用VS提供的配置文件编辑器修改其配置文件，就可以了。

掌握TCP/IP、Http、Soap协议对.NET编程有什么用?

网络客户端软件是经常需要开发的软件，掌握网络基础网络协议，对于这类客户端软件开发有非常多的好处，底层机制了解了，才能写出高效的通信软件。 想精通这些，锐英源有相关的视频，请关注下。

初步理解一下：SOA, SOAP, Web Serv, WSDL等

什么是SOA、SOAP?

SOA到底是什么？

SOA（Serv-Oriented Architecture）的定义是面向服务的架构，就是说将软件按照功能设计成一个个服务，这些服务用标准的方式定义接口、并通过标准的协议进行调用。 SOA所定义的接口和调用方式是于编程语言和运行平台的，广义上讲SOA可以基于不同的底层技术实现，比如CORBA和Web Servs。但CORBA由于过于复杂和臃肿已很少使用，所以目前所说的SOA绝大多数是基于Web Servs技术实现。在Web Servs的实现方式下，SOA服务的接口用XML进行定义。

在SOA架构下，软件开发从业务流程分析开始，使用组件化业务建模的方法识别和分析各种业务模型，将各种实践融入其中，在这个基础上建立用例，用例直接产 生BPEL，这些BPEL则可以被融入一个服务整合框架中，其描述了各种服务的信息，从而把ESB上的各个模块统一起来，形成一个巨大的服务仓。

将中间层再进行抽离，在中间层作一个跨技术架构的元数据和业务逻辑，使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产，也就 是面向服务的组件库，而且这个服务组件库也可以被其它企业复用，且不依赖于任何一种技术架构。夸张一点说，如果所有软件企业都使用SOA架构，那么世界软 件业将会发生的改变。显然，这样一个框架不是一种产品，也不仅仅是一种技术，而是一种解决问题的方。

SOA可能应用于两个场景：种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在种场景中，当不同企业 之间的业务需要相互调用，这时就可能采用SOA技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用SOA技术定义的原有数据和业务流程，可以很 快完成。

SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT 变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-Time Enterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户 化和人员技能的投入等方面取得了不错的成绩。

SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计 应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可 替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式 而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。

SOA也不仅仅是一种开发的方--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模 块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理 人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户 的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应 用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基 于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术 所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加地表示业务模型、更好地支持业务流程。相反我们可以看到以应 用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。

企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互作的专门方 法。例如，会计可能是企业服务系统的一个组件--但是将寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务 组件在流程和逻辑实现过程中的装配作。理解业务流程是定制服务的关键所在。

有利于企业业务的集成传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集 成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。

SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。

不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。

SOA 帮助企业信息系统迁移到"lee-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。

Soap是什么？

SOAP 是Simple Object Access Protocol（简单对象访问协议）的缩写。

SOAP是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议.

对于Soap的理解：

步理解：SOAP＝HTTP＋XML

第二步理解：SOAP把XML的使用代码化为请求和响应参数编码模式，并用HTTP作传输。

SOAP是把成熟的基于HTTP的WEB技术与XML的灵活性和可扩展性组合在了一起。

第三步理解：具体地讲，一个SOAP实现可以简单地看作遵循SOAP编码规则的HTTP请求和响应。

注意：SOAP 是一个协议，与编程语言无关。实际上，许多语言已经开始支持 SOAP，如：Ja，C，C＋＋以及JaScript。

Soap的起源？Soap解决的问题？

SOAP最初由微软发起研究，用以解决MTS/COM资源消耗大，不够轻巧等问题，后逐渐被IBM等巨头接纳并加入研究，现已提交W3C，成为Web Serv应用传输标准。SOAP技术主要用于实现大量异构程序和平台之间的互作性，从而使存在的应用能够被广泛的用户所访问。

SOAP意思是简单对象访问协议（Simple Object Access Protocol）。的确如它的名字一样，SOAP是很简单的。它是一个基于XML的协议，允许程序组件和应用程序彼此使用一种标准的Internet协 议--HTTP来通讯。SOAP是一种的平台，它不依赖程序语言，它是简单的，弹性的，很容易扩展的。目前，应用程序能够彼此使用一种基于DCOM和 CORBA技术的远程过程调用（RPC）来进行相互通讯，但HTTP不被设计为这个目的。RPC在Internet上应用是非常困难的，它们会出现许多兼 容性和安全性的问题，因为防火墙和通常都会阻断（block）这些类型的流量。应用程序之间的通讯方式是通过HTTP协议，因为HTTP是 支持所有Internet浏览器和的。基于这个目的，SOAP协议被创建出来。

SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义 了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。

虽然这四个部分都作为SOAP的一部分，作为一个整体定义的，但他们在功能上是相交的、彼此的。特别的，信封和编码规则是被定义在不同的XML命名空间(namespace)中，这样使得定义更加简单。

什么是CXF？

Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，现在已经正式更名为 Apache CXF 了，以下简称为 CXF。CXF 继承了 Celtix 和 XFire 两大开源项目的精华，提供了对 JAX-WS 全面的支持，并且提供了多种 Binding 、DataBinding、Transport 以及各种 Format 的支持，并且可以根据实际项目的需要，采用代码优先（Code First）或者 WSDL 优先（WSDL First）来轻松地实现 Web Servs 的发布和使用。目前它仍只是 Apache 的一个孵化项目。

Apache CXF 是一个开源的 Servs 框架，CXF 帮助您利用 Frontend 编程 API 来构建和开发 Servs ，像 JAX-WS 。这些 Servs 可以支持多种协议，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS 或者 JBI，CXF 大大简化了 Servs 的创建，同时它继承了 XFire 传统，一样可以天然地和 Spring 进行无缝集成。

CXF 包含了大量的功能特性，但是主要集中在以下几个方面：

支持 Web Servs 标准：CXF 支持多种 Web Servs 标准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。

Frontends：CXF 支持多种“Frontend”编程模型，CXF 实现了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一个“ frontend”允许客户端和 EndPoint 的创建，而不需要 Annotation 注解。CXF 既支持 WSDL 优先开发，也支持从 Ja 的代码优先开发模式。

容易 使用： CXF 设计得更加直观与容易使用。有大量简单的 API 用来快速地构建代码优先的 Servs，各种 Men 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加简化的 XML 配置方式，等等。

支持二进制和遗留协议：CXF 的设计是一种可插拨的架构，既可以支持 XML ，也可以支持非 XML 的类型绑定，比如：JSON 和 CORBA。

我们来利用cxf创建一个简单的webserv吧。

首先cxf 所需要的包：更具网站说明以下的包都是必须的，但是在我的实际项目中红色部分的包并没有用到。

大家可更具自己需求来添加适应的包。

cxf.jar

commons-logging.jar

geronimo-activation.jar (Or the Sun equivalent)//

geronimo-annotation.jar (Or the Sun equivalent)//

geronimo-jamail.jar (Or the Sun equivalent)//

nei.jar

jaxb-api.jar

jaxb-impl.jar

stax-api.jar//

XmlSchema.jar

wstx-asl.jar

xml-resolver.jar

分布式应用程序和浏览器

研究一下当前的应用程序开发，你会发现一个的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为 它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和之间通信的问题。

传统的Windows富客户应用程序使用DCOM来与进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的 工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是 一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问 你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

关于客户端与的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

许多商用程序还面临另一个问题，那就是与其他程序的互作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上， 那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前 还有很多商用程序继续在使用C++、Ja、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任 务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以 前，没有一个应用程序通信标准，是于平台、组建模型和编程语言的。只有通过Web Serv，客户端和才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是WebServ?

Web servs是建立可互作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

Web serv平台是一套标准，它定义了应用程序如何在Web上实现互作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web serv ，只要我们可以通过Web serv标准对这些服务进行查询和访问。

Web serv平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互作性，Web serv平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面 (intece)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web serv平台也必须提供一种标准来描述Web serv，让客户可以得到足够的信息来调用这个Web serv。，我们还必须有一种方法来对这个Web serv进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互作性，这种RPC协议还必须与平台和编程语言无关。

Web Serv 是一种新的web应用程序分支，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。Web Serv可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Serv应用程序可以发现并调用它部署的服务。

Web Serv是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。

1 历史

web广泛用到的技术：

◆TCP/IP：通用网络协议，被各种设备使用

◆HTML：通用用户界面，可以使用HTML标签显示数据

◆Ja：写一次可以在任何地方运行的通用编程语言

◆XML ：通用数据表达语言，在web上传送机构化数据的容易方法

他们的特点是其开放性，跨平台性，开放性正是Web servs的基础。

2 Web发展的趋势

内容更动态化

◆带宽Bandwidth更便宜，易于获得

◆存储器Storage更便宜，更易获得

◆普遍式计算变得更加重要：大量的设备，例如移动电话，页面，电脑，pc，已经在Internet上变得普遍，平台变得更多元化，象XML这样的跨平台技术变得更重要

3 Web Servs扮演什么角色？

上述的这些趋势意味着，更加智能的处理，作和汇总内容变得十分重要。让我们看看按照Web servs角度所预示的四个趋势：

◆内容更加动态：一个web serv必须能合并从多个不同源来的内容，可以包括股票，天气，等，在传统环境中的内容，如存货水平，购物订单或者目录信息等，都从后端系统而来

◆带宽更加便宜：web servs可以分发各种类型的内容（音频，视频流等）

◆存储更便宜: web servs必须能聪明地处理大量数据，意味着要使用数据库，LDAP目录，缓冲，和负载平衡软件等技术保持可扩展能力

◆普遍式计算更重要：web servs不能要求客户使用某一版本的windows的传统浏览器，必须支持各种设备，平台，浏览器类型，各种内容类型。

4 两种重要技术

要达到这样的目标，Web servs要使用两种技术：

◆XML XML是在web上传送结构化数据的伟大方式，Web servs要以一种可靠的自动的方式作数据，HTML不会满足要求，而XML可以使web servs十分方便的处理数据，它的内容与表示的分离十分理想

◆SOAP SOAP使用XML消息调用远程方法，这样web servs可以通过HTTP协议的t和get方法与远程机器交互，而且，SOAP更加健壮和灵活易用。

其他象UDDI和WSDL技术与XML和SOAP技术紧密结合用于服务发现。

组成Web serv平台的这三个技术。

XML和XSD

可扩展的标记语言(XML)是Web serv平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。

XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是 64位？这些细节对实现互作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web serv平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web serv时，为了符合Web serv标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换 过程。

WSDL

你会怎样向别人介绍你的Web serv有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web serv的人。这些非正式的方法至少都有一个的问题：当程序员坐到电脑前，想要使用你的Web serv的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web serv。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web serv描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web serv及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具 既能根据你的Web serv生成WSDL文档，又能导入WSDL文档，生成调用相应Web serv的代码。

各网络层安全协议有哪些

应用层

·DHCP(动态主机分配协议)

· DNS (域名解析）

· FTP（File Transfer Protocol）文件传输协议

· Gopher （英文原义：The Internet Gopher Protocol 中文释义：（RFC-1436）网际Gopher协议）

· HTTP （Hypertext Transfer Protocol）超文本传输协议

· IMAP4 (Internet Message Access Protocol 4) 即 Internet信息访问协议的第4版本

· IRC （Internet Relay Chat ）网络聊天协议

· NNTP （Network News Transport Protocol）RFC-977）网络传输协议

· XMPP 可扩展消息处理现场协议

· POP3 (Post Off Protocol 3)即邮局协议的第3个版本

· SIP 信令控制协议

· SMTP （Simple Mail Transfer Protocol）即简单邮件传输协议

· SNMP (Simple Network Mament Protocol,简单网络管理协议)

· SSH （Secure Shell）安全外壳协议

· TELNET 远程登录协议

· RPC （Remote Procedure Call Protocol）（RFC-1831）远程过程调用协议

· RTCP （RTP Control Protocol）RTP 控制协议

· RTSP （Real Time Streaming Protocol）实时流传输协议

· TLS （Transport Layer Security Protocol）安全传输层协议

· SDP( Session Description Protocol）会话描述协议

· SOAP （Simple Object Access Protocol）简单对象访问协议

· GTP 通用数据传输平台

· STUN （Simple Trersal of UDP over NATs，NAT 的UDP简单穿越）是一种网络协议

· NTP （Network Time Protocol）网络校时协议

传输层

·TCP（Tranission Control Protocol）传输控制协议

· UDP (User Datagram Protocol）用户数据报协议

· D （Datagram Congestion Control Protocol）数据报拥塞控制协议

· SCTP（STREAM CONTROL TRANSMISSION PROTOCOL）流控制传输协议

· RTP(Real-time Transport Protocol或简写RTP）实时传送协议

· RSVP （Resource ReSer Vation Protocol）资源预留协议

· PPTP ( Point to Point Tunneling Protocol）点对点隧道协议

网络层

IP(IPv4 · IPv6) Internet Protocol（网络之间互连的协议）

ARP : Address Resolution Protocol即地址解析协议，实现通过IP地址得知其物理地址。

RARP :Rrse Address Resolution Protocol 反向地址转换协议允许局域网的物理机器从的 ARP 表或者缓存上请求其 IP 地址。

ICMP :（Internet Control Message Protocol）Internet控制报文协议。它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。

ICMPv6:

IGMP :Internet 组管理协议（IGMP）是因特网协议家族中的一个组播协议，用于IP 主机向任一个直接相邻的路由器报告他们的组成员情况。

RIP : 路由信息协议（RIP）是一种在与主机之间交换路由选择信息的标准。

OSPF :(Open Shortest Path First开放式最短路径优先).

BGP :（Border Gateway Protocol ）边界协议，用来连接Internet上系统的路由选择协议

IS-IS:（Intermediate System to Intermediate System Routing Protocol）中间系统到中间系统的路由选择协议.

IPsec:“Internet 协议安全性”是一种开放标准的框架结构，通过使用加密的安全服务以确保在 Internet 协议 (IP) 网络上进行保密而安全的通讯。

数据链路层

802.11 · 802.16 · Wi-Fi · WiMAX · ATM · DTM · 令牌环 · 以太网 · FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN

IP,ARP,RARP,ICMP.

用tcp完成SOAP数据传输应该怎么实现

1.采用面向连接的三次握手实现可靠对象传输。

2.使用数据窗口机制协商队列大小实现数据队列传输。

3.通过序列化应答和必要时重发数据包，TCP 为应用程序提供了可靠的传输流和虚拟连接服务。

下面是找到的长篇大论中比较好的文章：

一、TCP协议

1、TCP 通过以下方式提供可靠性：

◆ 应用程序分割为TCP认为最合适发送的数据块。由TCP传递给IP的信息单位叫做报文段。

◆ 当TCP发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能记时收到一个确认，它 就重发这个报文段。

◆ 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常延迟几分之一秒。

◆ TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化如果收到报文段的检验和有错，TCP将丢弃这个报文段和不确认收到这个报文段。

◆ 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能失序，因此TCP报文段的到达也可能失序。如果必要，TCP将对收到的数据进行排序，将收到的数据以正确的顺序交给应用层。

◆ 既然IP数据报会发生重复，TCP连接端必须丢弃重复的数据。

◆ TCP还能提供流量控制，TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

另外，TCP对字节流的内容不作任何解释。

2、TCP首部：

TCP数据被封装在一个IP数据报中，格式如下：

IP首部20 TCP首部20 TCP首部

TCP首部格式如下：

16位源端口号 16位目的端口号

32位序号

32位确认序号

4位首度 保留6位 U

RG A

CK P

SH R

ST S

YN F

IN 16位窗口大小

16位检验和 16位紧急指针

选项

数据

说明：

（1）每个TCP段都包括源端和目的端的端口号，用于寻找发送端和接收端的应用进程。这两个值加上IP首部的源端IP地址和目的端IP地址确定一个TCP连接。

（2）序号用来标识从TCP发送端向接收端发送的数据字节流，它表示在这个报文段中的个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。

（3）当建立一个新连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN，该主机要发送数据的个字节的序号为这个ISN加1，因为SYN标志使用了一个序号。

（4）既然每个被传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当时上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。

（5）发送ACK无需任何代价，因为32位的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。

（6）TCP为应用层提供全双工的服务。因此，连接的每一端必须保持每个方向上的传输数据序号。

（7）TCP可以表述为一个没有选择确认或否认的华东窗口协议。因此TCP首部中的确认序号表示发送方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。

（8）首度需要设置，因为任选字段的长度是可变的。TCP首部最多60个字节。

（9）6个标志位中的多个可同时设置为1

◆ URG－紧急指针有效

◆ ACK－确认序号有效

◆ PSH－接收方应尽快将这个报文段交给应用层

◆ RST－重建连接

◆ SYN－同步序号用来发起一个连接

◆ FIN－发送端完成发送任务

（10）TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口大小是一个16为的字段，因而窗口大小为65535字节。

（11）检验和覆盖整个TCP报文端：TCP首部和TCP数据。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。TCP检验和的计算和UDP首部检验和的计算一样，也使用伪首部。

（12）紧急指针是一个正的偏移量，黄蓉序号字段中的值相加表示紧急数据一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。

（13）最常见的可选字段是最长报文大S，每个连接方通常都在通信的个报文段中指明这个选项。它指明本端所能接收的长度的报文段。

二、TCP连接的建立和终止

1、建立连接协议

（1） 请求端发送一个SYN段指明客户打算连接的的端口，隐疾初始序号(ISN)，这个SYN报文段为报文段1。

（2） 端发回包含的初始序号的SYN报文段（报文段2）作为应答。同时将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。

（3） 客户必须将确认序号设置为的ISN加1以对的SYN报文段进行确认（报文段3）。

这3个报文段完成连接的建立，称为三次握手。发送个SYN的一端将执行主动打开，接收这个SYN并发回下一个SYN的另一端执行被动打开。

2、连接终止协议

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

（1） TCP客户端发送一个FIN，用来关闭客户到的数据传送（报文段4）。

（2） 收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。

（3） 关闭客户端的连接，发送一个FIN给客户端（报文段6）。

（4） 客户段发回确认，并将确认序号设置为收到序号加1（报文段7）。

3、连接建立的超时

如果与无法建立连接，客户端就会三次向发送连接请求。在规定的时间内未应答，则连接失败。

4、报文段长度MSS

报文段长度表示TCP传往另一端的块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。

一般，如果没有分段发生，MSS还是越大越好。报文段越大允许每个报文段传送的数据越多，相对IP和TCP首部有更高的网络利用率。当TCP发送一个 SYN时，它能将MSS值设置为外出接口的MTU长度减去IP首部和TCP首度。对于以太网，MSS值可达1460。

如果目的地址为非本地的，MSS值通常默认为536，是否本地主要通过网络号区分。MSS让主机限制另一端发送数据报的长度，加上主机也能控制它发送数据报的长度，这将使以较小MTU连接到一个网络上的主机避免分段。

5、 TCP的半关闭

TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，这就是TCP的半关闭。

客户端发送FIN，另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后，才发送FIN关闭这个方向的连接，客户端再对这个FIN确认，这个连接才关闭。

6、2MSL连接

TIME_WAIT状态也称为2MSL等待状态。每个TCP必须选择一个报文段生存时间（MSL）。它是任何报文段被丢弃前在网络的最长时间。

处理原则：当TCP执行一个主动关闭，并发回一个ACK，该连接必须在TIME_WAIT状态停留的时间为2MSL。这样可以让TCP再次发送的ACK以避免这个ACK丢失（另一端超时并重发的FIN）。这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口不能被使用。

7、平静时间

TCP在重启的MSL秒内不能建立任何连接，这就是平静时间。

8、FIN_WAIT_2状态

在FIN_WAIT_2状态我们已经发出了FIN，并且另一端也对它进行了确认。只有另一端的进程完成了这个关闭，我们这端才会从 FIN_WAIT_2状态进入TIME_WAIT状态。这意味着我们这端可能永远保持这个状态，另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭。

9、复位报文段

TCP首部的RST位是用于复位的。一般，无论合适一个报文端发往相关的连接出现错误，TCP都会发出一个复位报文段。主要情况：

（1）到不存在的端口的连接请求；

（2）异常终止一个连接。

10、同时打开

为了处理同时打开，对于同时打开它仅建立一条连接而不是两条连接。两端几乎在同时发送SYN，并进入SYN_SENT状态。当每一端收到SYN时，状态变为SYN_RCVD，同时他们都再发SYN并对收到的SYN进行确认。当双方都收到SYN及相应的ACK时，状态都变为ESTABLISHED。一个同时打开的连接需要交换4个报文段，比正常的三次握手多了一次。

11、 同时关闭

当应用层发出关闭命令，两端均从ESTABLISHED变为FIN_WAIT_1。这将导致双方各发送一个FIN，两个FIN经过网络传送后分别到达另一端。收到FIN后，状态由FIN_WAIT_1变为CLOSING，并发送的ACK。当收到的ACK，状态变为TIME_WAIT。同时关闭和正常关闭的段减缓数目相同。

12、TCP选项

每个选项的开始是1字节的kind字段，说明选项的类型。

Kind=1:选项表结束（1字节） Kind=1:无作（1字节） Kind=2：报文段长度（4字节） Kind=3:窗口扩大因子（4字节） Kind=8:时间戳（10字节）

三、TCP的超时和重传

对于每个TCP连接，TCP管理4个不同的定时器。

（1） 重传定时器用于当希望收到另一端的确认。

（2） 坚持定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。

（3） 保活定时器可检测到一个空闲连接的另一端何时崩溃或重启。

（4） 2MSL定时器测量一个连接处于TIME_WAIT状态的时间。

1、往返时间测量

TCP超时和重传重最重要的就是对一个给定连接的往返时间（RTT）的测量。由于路由器和网络流量均会变化，因此TCP应该跟踪这些变化并相应地改变超时时间。首先TCP必须测量在发送一个带有特别序号地字节和接收到包含该字节地确认之间的RTT。

2、拥塞避免算法

该算法定由于分组收到损坏引起的丢失是非常少的，因此分组丢失就意味着在源主机和目的主机之间的某处网络上发生了阻塞。有两种分组丢失的指示：发生超时和收到重复的确认。拥塞避免算法需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。

(1) 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。

(2) TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。

(3) 当拥塞发生时，ssthresh被设置为当前窗口大小的一般(cwnd和接收方通告窗口大小的最小值，但最小为2个报文段)。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段。

(4) 当新的数据被对方确认时，就增加cwnd，但增加的方法依赖与是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。

3、快速重传和快速恢复算法

如果我们一连串收到3个或以上的重复ACK，就非常可能是一个报文段丢失了。于是我们就重传丢失的数据报文段，而无需等待超时定时器溢出。

（1） 当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半，重传丢失的报文段，设置cwnd为ssthresh加上3倍的报文段大小。

（2） 每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送一个1个分组，如果允许的话。

（3）当下一个确认新数据的ACK到达时，设置cwnd为ssthresh，这个ACK应该时在进行重传后的一个往返时间内对步骤1重重传的确认。另外，这个 ACK也应该是对丢失的分组和收到的个重复的ACK之间的所有中间报文段的确认。

4、 ICMP错

TCP如何处理一个给定的连接返回的ICMP错。TCP能够遇到的最常见的ICMP错就是源站抑制、主机不可达和网络不可达。

（1） 一个接收到的源站抑制引起拥塞窗口cwnd被置为1个报文段大小来发起慢启动，但是慢启动门限ssthresh没有变化，所以窗口将打开直到它开放了所有的通路或者发生了拥塞。

（2） 一个接收到的主机不可达或网络不可达实际都被忽略，因为这两个错都被认为是短暂现象。TCP试图发送引起该错的数据，尽管最终有可能会超时。

5、重新分组：

当TCP超时并重传时，它并不一定要重传同样的报文段，相反，TCP允许进行重新分组而发送一个较大的报文段。这是允许的，因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。

四、TCP的坚持定时器

ACK的传输并不可靠，也就是说，TCP不对ACK报文段进行确认，TCP只确认那些包含数据的ACK报文段。为了防止因为ACK报文段丢失而双方进行等待的问题，发送方用一个坚持定时器来周期性地向接收方查询。这些从发送方发出地报文段称为窗口探查。

五、TCP的保活定时器

如果一个给定的连接在2小时内没有任何动作，那么就向客户发送一个探查报文段。客户主机必须处于以下4个状态之一。

(1) 客户主机依然正常运行，并从可达。客户的TCP响应正常，而也知道对方的正常工作的。在2小时内将保活定时器复位。

(2) 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。将不能收到对探查的响应，并在75秒后超时。总共发送10个探查，间隔75秒。

(3) 客户主机崩溃并已经重新启动。这是将收到一个对其保活探查的响应，但这个响应是一个复位，使得终止这个连接。

(4) 客户主机正常运行，但是从不可达。

六、TCP的一些性能

1、 路径MTU发现：

TCP的路径MTU发现按如下方式进行：在连接建立时，TCP使用输出接口或对段声明的MSS中的最下MTU作为其实的报文段大小。路径MTU发现不允许TCP超过对端声明的MSS。如果对端没有指定一个MSS，则默认为536。

一旦选定了起始的报文段大小，在该连接上的所有被TCP发送的IP数据报都将被设置DF位。如果中间路由器需要对一个设置了DF标志的数据报进行分片，它就丢弃这个数据报，并产生一个ICMP的“不能分片”错。

如果收到这个ICMP错，TCP就减少段大小并进行重传。如果路由器产生的是一个较新的该类ICMP错，则报文段大小被设置位下一跳的MTU减去 IP和TCP的首度。如果是一个较旧的该类ICMP错，则必须尝试下一个可能的最小MTU。

2、 长肥管道

一个连接的容量＝带宽X时延（RTT）。具有大的带宽时延乘积的网络称为长肥网络（LFN）。一个运行在LFN的TCP连接称为长肥管道。管道可以被水平拉长（一个长的RTT）,或被垂直拉高（较高的带宽），或两个方向拉伸。

3、窗口扩大选项：

窗口扩大选项使TCP的窗口定义从16位增加到32位，这并不是通过修改TCP首部来实现的，TCP首部仍然使用16位，而是通过定义一个选项实现对16位的扩大作来完成的。

4、时间戳选项：

时间戳选项使发送方在每个报文段中放置一个时间戳值。接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK计算RTT。

RPC、、tcp/ip、udp、socket以及soap协议都有什么相同点和不同点？

TCP/IP协议是一个协议簇。里面包括很多协议的。UDP只是其中的一个。之所以命名为TCP/IP协议，因为TCP,IP协议是两个很重要的协议，就用他两命名了。

tcp和udp都是传输协议，主要区别是tcp协议连接需要3次握手，断开需要四次握手，是通过流来传输的，就是确定连接后，一直发送信息，传完后断开。udp不需要进行连接，直接把信息封装成多个报文，直接发送。所以udp的速度更快写，但是不保证数据的完整性和数据顺序，（这个是可以在实现时通过验证手段来手动确定完整性）。

协议是建立在TCP协议之上的一种应用，是Web联网的基础，最显著的特点是客户端发送的每次请求都需要回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

socket并不是一种协议，是在程序员层面上对TCP/IP协议的封装和应用。其实是一个调用接口，方便程序员使用TCP/IP协议栈而已。程序员通过socket来使用tcp/ip协议。但是socket并不是一定要使用tcp/ip协议，Socket编程接口在设计的时候，就希望也能适应其他的网络协议。

rpc是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

初学情况下只要了解协议和调用协议，ja使用，还有socket编程就好了。RPC我也了解的不多。