rfc768(UDP协议标准文档)

RFC768J.PostelISI28August1980UserDatagramProtocol----------------------Introduction------------ThisUserDatagramProtocol(UDP)isdefinedtomakeavailableadatagrammodeofpacket-switchedcomputercommunicationintheenvironmentofaninterconnectedsetofcomputernetworks.ThisprotocolassumesthattheInternetProtocol(IP)[1]isusedastheunderlyingprotocol.Thisprotocolprovidesaprocedureforapplicationprogramstosendmessagestootherprogramswithaminimumofprotocolmechanism.Theprotocolistransactionoriented,anddeliveryandduplicateprotectionarenotguaranteed.ApplicationsrequiringorderedreliabledeliveryofstreamsofdatashouldusetheTransmissionControlProtocol(TCP)[2].Format------0781516232431+--------+--------+--------+--------+|Source|Destination||Port|Port|+--------+--------+--------+--------+||||Length|Checksum|+--------+--------+--------+--------+||dataoctets...+----------------...UserDatagramHeaderFormatFields------SourcePortisanoptionalfield,whenmeaningful,itindicatestheportofthesendingprocess,andmaybeassumedtobetheporttowhichareplyshouldbeaddressedintheabsenceofanyotherinformation.Ifnotused,avalueofzeroisinserted.Postel[page1]28Aug1980UserDatagramProtocolRFC768FieldsDestinationPorthasameaningwithinthecontextofaparticularinternetdestinationaddress.Lengthisthelengthinoctetsofthisuserdatagramincludingthisheaderandthedata.(Thismeanstheminimumvalueofthelengthiseight.)Checksumisthe16-bitone’scomplementoftheone’scomplementsumofapseudoheaderofinformationfromtheIPheader,theUDPheader,andthedata,paddedwithzerooctetsattheend(ifnecessary)tomakeamultipleoftwooctets.ThepseudoheaderconceptuallyprefixedtotheUDPheadercontainsthesourceaddress,thedestinationaddress,theprotocol,andtheUDPlength.Thisinformationgivesprotectionagainstmisrouteddatagrams.ThischecksumprocedureisthesameasisusedinTCP.0781516232431+--------+--------+--------+--------+|sourceaddress|+--------+--------+--------+--------+|destinationaddress|+--------+--------+--------+--------+|zero|protocol|UDPlength|+--------+--------+--------+--------+Ifthecomputedchecksumiszero,itistransmittedasallones(theequivalentinone’scomplementarithmetic).Anallzerotransmittedchecksumvaluemeansthatthetransmittergeneratednochecksum(fordebuggingorforhigherlevelprotocolsthatdon’tcare).UserInterface--------------Auserinterfaceshouldallowthecreationofnewreceiveports,receiveoperationsonthereceiveportsthatreturnthedataoctetsandanindicationofsourceportandsourceaddress,andanoperationthatallowsadatagramtobesent,specifyingthedata,sourceanddestinationportsandaddressestobesent.[page2]Postel28Aug1980RFC768UserDatagramProtocolIPInterfaceIPInterface-------------TheUDPmodulemustbeabletodeterminethesourceanddestinationinternetaddressesandtheprotocolfieldfromtheinternetheader.OnepossibleUDP/IPinterfacewouldreturnthewholeinternetdatagramincludingalloftheinternetheaderinresponsetoareceiveoperation.SuchaninterfacewouldalsoallowtheUDPtopassafullinternetdatagramcompletewithheadertotheIPtosend.TheIPwouldverifycertainfieldsforconsistencyandcomputetheinternetheaderchecksum.ProtocolApplication--------------------ThemajorusesofthisprotocolistheInternetNameServer[3],andtheTrivialFileTransfer[4].ProtocolNumber---------------Thisisprotocol17(21octal)whenusedintheInternetProtocol.Otherprotocolnumbersarelistedin[5].References----------[1]Postel,J.,InternetProtocol,RFC760,USC/InformationSciencesInstitute,January1980.[2]Postel,J.,TransmissionControlProtocol,RFC761,USC/InformationSciencesInstitute,January1980.[3]Postel,J.,InternetNameServer,USC/InformationSciencesInstitute,IEN116,August1979.[4]Sollins,K.,TheTFTPProtocol,MassachusettsInstituteofTechnology,IEN133,January1980.[5]Postel,J.,AssignedNumbers,USC/InformationSciencesInstitute,RFC762,January1980.Postel[page3]