Útmutató az UDP-hez (User Datagram Protocol)

A felhasználói adatgram protokoll olyan, mint Hans Christian Andersen „Csúnya kiskacsa”. Miután figyelmen kívül hagyták és nevetségessé tették ezt az egyszerű protokollt, évtizedek óta hirtelen vonzza a csodálókat, mint a szélessávú sebesség által lehetővé tett új, elbűvölő multimédiás alkalmazások szállítási protokollja. Manapság bármely alkalmazás, amelynek adatokat kell szolgáltatnia, az UDP-t választja a korábban domináns TCP (Transmission Control Protocol) felett.

UDP története

Az UDP szinte olyan hosszú ideig létezett, mint az internet. Az internet 1974 májusában jött létre, amikor a Villamos- és Elektronikusmérnökök Intézete közzétette „Program csomagkapcsolt hálózatok közötti kommunikációhozÍrta: Vint Cerf és Bob Khan. A koncepciót tovább kellett fejleszteni, és Khan és Cerf egyaránt tovább finomították ötleteiket, miközben az Egyesült Államok kormányának dolgoztak Védelmi Haladó Kutatási Projektek Ügynöksége, amelyet DARPA néven is ismert. John Postel bekapcsolódott és javasolta a Cerf és Khan eredeti ötletében javasolt egységes struktúra felosztását. Ez rétegelt koncepciót hozott létre. Az eredeti, az 1974. évi vázlatban szereplő átviteli vezérlőprogramot egy magasabb rétegű átviteli vezérlő protokollra és egy alacsonyabb rétegű átviteli vezérlő protokollra osztották (tehát TCP / IP)..

A Postel moduláris megközelítésének akkor volt értelme, amikor a csapat elkezdte gondolkodni az elmélet megvalósításán. Világos volt a munkamegosztás az ún Szállítási réteg, amely az átviteli vezérlő protokoll helye, és Internet réteg, ahol az Internet Protokoll található. Cerf és Khan azonban úgy gondolta, hogy gyorsított megoldásra van szükség. Rajzoltak egy diagramot, amely szerint az adatok egy rétegről a másikra történő továbbításával felkészülnek az átvitelre. A feldolgozási feladatokat egyenes függőleges vonalként ábrázoltuk, lefelé haladva az új veremdiagramjukon, amely megmutatta az előrehaladást alkalmazás a TCP-hez és az IP-hez.

Mikor a gyorsított rajzra volt szükség, nem akartak, hogy egy görbe kitérővonalat húzzanak, amely elkerüli a TCP-n keresztüli áthaladást. Ehelyett egy hosszúkás alakzatot rajzoltak, amely kissé szélesebb körben reprezentálja az Internet réteget, mint a Közlekedési réteget képviselő blokk. Ezzel a vizuális beállítással mind a normál, mind a gyorsjáratú útvonal párhuzamos vonalakként ereszkedhet le a veremben. Ez a trükk azonban rést hagyott, amelyet Postel szerint ki kellett tölteni. Ezért találták ki a felhasználói adatgram protokollt. Éppen ott volt, hogy a protokoll-verem diagram kiegyensúlyozott legyen.

A TCP előnyei

Az átviteli vezérlő protokoll alapvető szolgáltatásokat nyújt az áthaladó adatok számára. Biztosítja, hogy az adatfolyamban lévő összes csomag ténylegesen megérkezzen, és ellenőrzi, hogy rendben vannak-e. Ezek az ellenőrzési eljárások, amelyek biztosítják a szabályos átadást, a két fél közötti koordináció mértékének nélkül nem lehetségesek. Tehát a TCP először megállapodást köt a két eszköz között, amelyek adatcserét kívánnak folytatni. Ezt a megállapodást hívják egy ülés. Ez egyben a „kapcsolat.„Az UDP-nek nincsenek munkamenet-létrehozási eljárásai, és ezért azt nevezzük“kapcsolat nélküli.”

Az ülés a kapcsolat mindkét oldalához hivatkozási számot ad, amelyet megcímkézhetnek adminisztratív központjukba. Az ülés lehetővé teszi a kikötők koncepciójának bevezetését. A munkamenet azonosítója valójában a TCP fejlécében található azonosítók kombinációja. Ezzel az azonosítóval a TCP eljárások tervezői előálltak egy „foglalat.A portszámokat az UDP-hez is kiosztják, azonban a protokoll csak a rendeltetési hely IP-jét és a portszámokat használhatja egyedi azonosítóként. Az ebből a kombinációból származó azonosító blokkolja az összes többi, ugyanahhoz a porthoz való hozzáférést próbáló folyamatot, annak ellenére, hogy különböző számítógépeken futnak, tehát Az UDP-t csak kézbesítési rendszerré alakították, anélkül, hogy kétirányú párbeszédet engedélyeztek volna.

A TCP csatlakozási koncepciók mindegyike nagyon kifinomult univerzális módszerré fejlődött annak biztosítása érdekében, hogy a számítógépek közötti adatátvitel ne zavarodjon össze vagy zavarodjon meg. A foglalat lehetővé tette több kapcsolat megnyitását ugyanazon két számítógép között egyszerre. Ez az ötlet lehetőséget teremtett arra, hogy egynél több csatorna működjön az adatok továbbítására. Ez egy gyakran használt eljárás, amelyet sok korai hálózati alkalmazás kihasznált. Az File Transfer Protocol, például két csatornát használ: egyet az adatok továbbításához, és egy külön csatornát az adminisztratív kommunikációhoz. Az adat- és a vezérlőcsatornák különböző portszáma két különálló aljzatot hoz létre.

Az egyes munkamenetek egyedi azonosítója azt jelentette, hogy a TCP hozzáadott értéket jelentett a két számítógép közötti kommunikációhoz. A 70-es évek végén és a 80-as évek elején csak nagy szervezetek és tudományos intézmények rendelkeztek számítógépekkel és hálózatokkal. Tehát nagyon valószínű, hogy két szervezetnek szüksége volt nagy mainframe-jükre, hogy különböző célokra egyszerre csatlakozzanak egymáshoz. Amíg a professzor egy fájlt küldött egy másik egyetemen lévő kollégának, egy kutató esetleg szeretne Telnet-munkamenetet megnyitni a számítógépre ugyanabban a távoli egyetemen. A TCP-nek köszönhetően két számítógép több kapcsolatot képes fenntartani egyidejűleg, és ezek a munkamenetek több csatornát is működtethetnek egyszerre. Ez az egyidejű kapcsolat nem lehetséges, ha a kommunikációt csak az Internet Protokoll szabályozza, és számítógépénként egy IP-címet oszt ki. Az UDP – munkamenet-mechanizmus nélkül – nem volt képes kezelni azokat az alkalmazásokat, amelyekre a válasz elküldéséhez kapcsolatba lépő számítógéppel volt szükség.

Adatbiztonság

A TCP ragyogó konstrukciói lehetővé tették a kapcsolatok kialakítását a hálózatok között, és az internet az Academia-n túl is elterjedt az üzleti világ felé. A Világháló, amely 1991-ben nyilvánosságra került, csak azért volt lehetséges, mert a Hypertext Transfer Protocol (HTTP) hordozó weboldal könnyű volt a TCP tetején ülni..

Azok az akadémikusok és technikusok, akik összeállították az internetet, majd kifejlesztették a nyilvánosan elérhető világhálót kék ég gondolkodók. Izgatott volt a technológia és annak lehetősége, hogy felgyorsítsák a kutatást és javítsák az emberek közötti interakciót az egész világon. Nem vették figyelembe azt a tényt, hogy csodálatos találmányuk ajándékként szolgált tolvajok, művészek és városi terroristák számára. Sem az internet, sem a világháló egyáltalán nem volt biztonságban.

A fogyasztó vezérelte Netscape Corporation hogy észrevegye ezt a problémát. A Netscape elkészítette a világ vezető webböngészőjét, és ingyen kiadta, hogy ösztönözze az internet elterjedését a lakosság körében. A terv működött, az információcsere és a kapcsolattartási csatornák szétszóródtak, ösztönözve a közvélemény további tagjait az Internet-szolgáltatásokra való feliratkozásra. Azonban a a biztonság hiánya akadályt jelentett a web kereskedelme szempontjából. Anélkül, hogy az embereket rá tudnák vonzani az online szolgáltatások fizetésére, nem ösztönözte a vállalkozásokat arra, hogy új alkalmazások, webhelyek vagy online szolgáltatások fejlesztésébe fektessenek be..

A fizetés interneten keresztüli beszedésének legnagyobb akadálya a biztonság hiánya volt. Az internetes adatátvitel néhány címsora lezárta annak lehetőségét, hogy az internetet gazdaságilag életképessé tegye. azonban, A Netscape bemutatta a HTTPS-t – a HTTP biztonságos verziója, amely védi az átvitelt. A biztonsági eljárások ideális helyét a TCP / IP veremben a TCP munkamenet-létrehozási folyamatain végezték el. Így, A TCP még fontosabbá vált az internet működése szempontjából és még valószínűbbnek tűnt, hogy az UDP soha nem kerül felhasználásra.

Az UDP felszáll

Annak ellenére, hogy 1980 óta létezik, Az UDP-t teljesen figyelmen kívül hagyták amíg a szélessávú internet-szolgáltatások a század elején nem váltak elérhetővé. A User Datagram Protokollot nagymértékben figyelmen kívül hagyták, miközben a webes és egyéb internetes alkalmazások kibővítették a TCP funkcionalitását.

azonban, az a lehetőség, hogy hangbeszélgetések és videokonferenciák zajlanak az interneten keresztül, mindig vonzó volt a vállalkozások számára. Ezek az alkalmazások léteztek a szélessáv előtt, de csak gyorsabb magánhálózatokon való használatra. A hang és a videó átvitelének technológiájával a hálózatokon keresztül, a szélessávú sebesség gyorsabbá tette annak lehetőségét, hogy ezeket az alkalmazásokat a nyilvánosság számára is elérhetővé tegye megvalósítható ötletgé vált. Az interneten elérhető sebesség azonban nem volt elég jó.

Az elegendő extra sebességnek az internetről történő kiszorításának azonnali megoldása a TCP és a TCP összes adminisztratív eljárásának áthidalása volt forduljon a szinte elfeledett UDP-hez.

A TCP problémái

Az interaktív alkalmazások inkább a továbbítás során felmerült problémákkal foglalkoznak. A TCP egyik fő jellemzője, amelyet ezek az alkalmazások valóban nem akarnak pufferelés.

A TCP gondoskodik arról, hogy a csomagok egymás után érkezzenek. Ha hiányzik egy csomag az adatfolyamból, a fogadó TCP megvalósítás kérést küld a küldő TCP programnak az adott csomag újraküldésére. Időközben ez a csomag későn érkezhet be. A TCP csúszó keretrendszert használ az érkező csomagok feldolgozására, és ha egy szegmens késik vagy elveszik, akkor a dia elakad. Számos képkocka ideiglenes tárolása a memóriában az úgynevezett pufferelés. A TCP vár, amíg az üres helyet kitölti a hiányzó sorszámot viselő csomaggal. Internetes telefonálás esetén egy ilyen intézkedés a vezeték elnémulásához vezetne. Video streaming esetén a hiányzó csomag várakozása a videolejátszót lefagy.

Az interaktív alkalmazásoknak nincsenek eljárásai a TCP pufferelésének megkerülésére. A veremrétegek mögött az a fő, hogy a magasabb rétegek szolgáltatást igényelnek, és az alsó rétegre bocsátják, hogy biztosítsák. Nincs olyan jel, amelyet az alkalmazás küldhet a szállítási rétegre.

Ha egy csomag elveszik egy digitális telefonbeszélgetés során, akkor a hívók rövid csendet tapasztalnak meg, de az alkalmazás mindkét oldalon csak továbbmozdul, és folytatja a következő csomagok küldését és fogadását.. Mire a hiányzó csomag helyreállítható, az interaktív beszélgetés már folytatódott volna, tehát nincs értelme megpróbálni visszajuttatni azt az adatfolyamba.; jobb, ha leírjuk a veszteséget, és folytatjuk. Hasonlóképpen, az elveszett csomag egyszerűen csak egy rövid átugrást jelentene az élő videofolyamban, és a nézők sokkal inkább azt szeretnék, ha a videó tovább haladna, mint hogy a képkockát egymásodszor másodpercig tartsa..

Valószínűleg látott egy videolejátszó szünetet és átfedte a „pufferelés”A képen. Általában van egy számláló, amely megmutatja a befejezett pufferolás százalékos arányát. Ez a pufferelés akkor fordul elő, ha a kapcsolat átviteli sebessége lassabb, mint a videó lejátszásának képkockasebessége. Az üzenet döntő pontja azonban az, hogy azt mutatja, hogy a pufferelést a játékos kezeli, nem pedig a szállítási protokoll..

Partneri protokollok

Bár az interaktív alkalmazás nem akarta a TCP okozta késéseket, ők a protokoll néhány funkcióját megkívánják. Többet akartak, mint amit az UDP nyújthat. Tehát más protokollokat fedeztek fel a TCP képességeinek bizonyos részeinek kitöltésére.

A munkamenet-kezdeményezési protokoll

A Session Initiation Protocol (SIP) protokollt a Voice over IP (VoIP) alkalmazásokhoz fejlesztették ki. Az internetes telefonálás nem akarta a TCP pufferelését, ám a telefonok hagyományos hívásindítási eljárásait követniük kellett – tárcsázás, csengetés, foglalt, felvétel és befejezés. A SIP azonban nem kezeli a teljes munkamenetet, hanem csak a kapcsolat létrehozásával és a TCP lebontási funkcióival foglalkozik. Minden, az interneten keresztül folyó hívás a SIP-t használja. Annyira, hogy a „SIP” szinte felcserélhető kifejezés lett a „VoIP.”

A hangforgalom nagy sebességű digitális összeköttetéseken keresztül történő ömlesztett futtatása „SIP csatorna.”A hívás átvitele az internetről a szokásos vezetékes telefonra az úgynevezett„SIP megszüntetés.„A digitális telefonipar a SIP segítségével technológiáját azonosítja, de minden tevékenységük alapja az UDP.

A valós idejű szállítási protokoll

Annak ellenére, hogy úgy döntött, hogy a TCP túl sok volt az interaktív forgalom fölött, ezért le kell vetni, A kommunikációs mérnökök visszatértek a TCP által biztosított szolgáltatásokhoz és azt kívánják, hogy rendelkezzenek velük az UDP-vel. A Real-Time Transport Protocol (RTP) kompenzálja az UDP használata során tapasztalt funkcionális hiányosságokat.

Ezeknek a kiegészítő protokolloknak a kulcsfontosságú jellemzője, amelyek az UDP-t relevánssá teszik a média streamingben, hogy lehetővé teszik a TCP által hagyományosan kezelt folyamatok egy részének az alkalmazásba történő továbbítását. Az RTP kezeli a TCP forgalomkezelési funkcióit, de nem mindegyiket.

Az RTP képes a sorozatcsomagok újrarendelésére és az elveszett csomagok észlelésére. A szekvenálási funkciót azonban nem kell megvalósítani, és a szállítási réteg pufferolása nélkül lehetetlen megvalósítani.

Az RTP vezérlő protokoll

Az RTP mindig együttműködik az RTCP-vel, amely az RTP vezérlő protokoll. Az RTPC a TCP munkamenedzsment funkcióinak néhányat emulálja, kivéve a protokoll alapelve, hogy ne lépj be az adatfolyamba, és ne lassítsd le a médiaátvitelt; tehát tevékenysége ritka. A protokoll teljesítményadatokat gyűjt, ideértve a csomagvesztést is, és átviteli sebességre vonatkozó információk. A fogadó lejátszó ezeket az információkat felhasználhatja annak eldöntésére, hogy váltson-e a videó alacsonyabb felbontására, vagy más videokódolási szabványra.

Video és audio alkalmazás használata esetén szinte biztos, hogy mind az RTP, mind az RTCP részt vesz. Van egy “interleavelését”Lehetőséget az RTSP meghatározásában (lásd alább), amely az RTP átvitelt a TCP-re továbbítja. Ez azonban egy szokatlan javaslat, amelyet soha nem hajtottak végre a laboratóriumon túl. E specifikáció nélkül az összes RTP és RTCP tevékenységet az UDP végzi.

A Real Time Streaming Protocol

A Real Time Streaming Protocol (RTSP) szinte mindig részt vesz a video- és audiolejátszásban vagy a felvételi alkalmazásokban. Ez a protokoll vezérlőgombokat biztosít a lejátszón és a felvevőn. Ezek a Szünet, Felvétel / lejátszás, Gyors előre és Visszatekerés. Furcsa módon, bár az RTSP képes futni az UDP-n, általában TCP-n keresztül szállítják, annak ellenére, hogy egy UDP-támogatott video- vagy audiofolyammal társul..

Csak UDP alkalmazások

Számos könnyű hálózatot támogató alkalmazás használja az UDP-t olyan protokollok nélkül, amelyek a TCP funkcióinak szimulációját alkotják. Ezeket a funkciókat szinte kizárólag kizárólag magánhálózatokban való felhasználásra szánják mert nem tartalmaznak semmilyen hitelesítési eljárást vagy átviteli titkosítást.

Ha hálózatot kezel, akkor ismeri a Hálózati idő protokoll (NTP), az Domain névrendszer (DNS), az Dinamikus gazdagép konfigurációs protokoll (DHCP), és a Triviális fájlátviteli protokoll (TFTP). Az adminisztrációs szolgáltatások mindegyike az UDP-n fut. Ezen magánhálózati alkalmazásokon túl nagyon nehéz olyan alkalmazásokat találni, amelyek csak UDP-n futnak.

UDP vs TCP

Az UDP fejléc szerkezetének és a TCP fejléc szerkezetének összehasonlítása megmutatja az UDP korlátozásait.

Az UDP fejléce csak négy mezőt tartalmaz. A négy közül a Forrás port A mező nem kötelező, és üres lehet. Az IPv4-ben a ellenőrző A mező nem kötelező, bár kötelező az IPv6 megvalósításánál. Ez azt jelenti, hogy IPv4 átvitel esetén az UDP fejlécben csak két információt kell tartalmaznia.

A TCP fejléc sokkal több információt képes továbbítani.

Mint az ábrából látható, a TCP csomag fejlécében kilenc zászló található, amelyek adaptálják a fejléc jelentését. Az esemény „sürgős” mezőjével rendelkezik. Ez sokkal nagyobb rugalmasságot biztosít a TCP rendszer számára, mint az UDP, és azt mutatja, hogy sokkal több időt fordítottak a TCP eljárásaira és annak csomagfejléce struktúrájára, mint az UDP fejlesztésére fordítottak..

Az a tény, hogy a TCP fejlécének tartalmaznia kell a forrásportot, lehetővé teszi egyedibb socket létrehozását, a munkamenet azonosítójának létrehozásával a forrás és a cél IP címekből, valamint a forrás és a cél port számokból. Az UDP-vel, mivel nincs eljárása munkamenet létrehozására, minden üzenetet befejezett feladatként kezelünk, és a protokoll nem kísérel meg csomagokat összecsatolni. Ezért az USP-t használó alkalmazásoknak maguknak kell kezelniük ezt a folytonosságot.

Az UDP biztonsága

A TCP kapcsolatorientált módszerei sokkal könnyebbé teszik a biztonság megvalósítását abban a protokollban az UDP-ben. Vannak azonban titkosítási szabványok az UDP számára. Az UDP biztonságot közvetlenül célzó fő opció a Datagram Transport Layer Security protokoll vagy a DTLS.

szerencsére, A DTLS számos ingyenes, nyílt forráskódú könyvtárban elérhető, így nem kell átfésülnie a protokolldefiníción, és meg kell írnia a nyitott programot annak végrehajtásához. OpenSSL, amely a nyílt forráskód könyvtára, a leggyakoribb forrás a Transport Layer Security megvalósításához, amely a TCP legszélesebb körben megvalósított biztonsági rendszere. Ez a könyvtár is tartalmaz egy DTLS megvalósítást, így biztonságos UDP lehetőségeket kell találnia ugyanazon alkalmazásokban, amelyek biztonságos TCP kapcsolatot kínálnak.

Az UDP felhasználók egy másik lehetősége az, hogy támaszkodnak egy biztonsági rendszerre, amelyet úgy terveztek, hogy működjön az Internet rétegen. Ez IPSec, vagy Internet Protocol Security. Mivel az IPSec a szállítási réteg alatt működik, nem képes a portokkal együttműködni, és az a tény, hogy az UDP nem tudja fenntartani a munkamenetet, nem számít, ha az IPSec be van kapcsolva. – Az IP-rétegű protokollok sem hozhatnak létre munkameneteket. Alsó rétegű rendszerként, Az IPSec képes támogatni minden szállítási réteg protokollt, beleértve az UDP-t is.

Az IPSec hitelesítési módszereket is tartalmaz, és a csomagok titkosítását is védi a riasztó szimatolók ellen. Az IT ugyanolyan biztonságot nyújt, mint a népszerű TLS, de kevésbé valósul meg. Az IPSec az Internet Key Exchange (IKEv2) rendszert használja a hitelesítés beállításához, így gyakran az IPSec számlázása IKEv2. Az IKEv2 módszertan használja Diffie-Hellman kulcscsere-eljárások, pontosan ugyanazt a rendszert használja, amelyet a TLS a HTTPS biztonságos weboldal-munkamenet módszerére használ.

A Kerberos és a kulcsok Kerberizált Internetes Tárgyalása (KINK) a biztonsági rendszer két eleme, amelyet általában Kerberosnak hívnak. A Kerberos munkamenet-létrehozási eljárásai a „jegyek” rendszerét alkalmazzák, amely hasonló a TLS „tanúsítványok” módszeréhez. A verem végén a Kerberot az IPSec támogatja. A néven szereplő Kerberos réteg az UDP tetején ül, és UDP aljzatokat épít fel a kommunikáció megkönnyítése érdekében. Tehát ez egy UDP-barát biztonsági rendszer. A Kerberos izgalmas lehetősége, hogy lehetővé teszi az AES titkosítás alkalmazását az UDP átvitel védelme érdekében. Az AES valószínűleg a legbiztonságosabb rejtjel a közös használatban manapság, és ez az ajánlott biztonsági módszer a világ legjobb VPN adatvédelmi rendszereire..

Annak ellenére, hogy a titkosítási kulcsok tárgyalása nyilvánvaló nehézségeket okoz olyan környezetben, amely nem biztosít semmilyen kapcsolatkezelést, az UDP biztonsági lehetőségeket kínál. Tehát, amikor egy UDP-alapú alkalmazást telepít, ne hagyja abba az átvitel biztosításának feladatát.

Az UDP jövője

A tiszta UDP-alapú alkalmazások, amelyek nem tartalmaznak oldalsó protokollokat a TCP utánozására, ritkák, és valószínűleg még ritkábbak. Az UDP-t használó könnyű hálózati segédprogramok biztonságos helyi hálózatokon fejlődnek. Mivel azonban az új, nulla napos támadások által okozott biztonsági fenyegetések minden héten növekednek, a konfigurációkezelés és a címzés kritikus szolgáltatásait kezelő bizonytalan protokollok hiábavalónak tűnnek..

Amint a hálózatok átviszik szolgáltatásaikat a felhőbe, az UDP-alapú TFTP és DHCP szolgáltatásait biztonságosabb alternatívák váltják fel.. Az alkalmazások szörfözésének könnyű megoldása a HTTPS-en keresztül, hogy biztonságot biztosítsanak számukra külön programozási erőfeszítések nélkül, a jövőt a TCP felé irányítja, amely a HTTPS-t hordozza, és kiküszöböli a lehetőségeket az UDP kompetenciák listájáról..

A médiaátvitel támogatásának UDP rése valószínűleg fennmarad. Az interaktív alkalmazások támogatására már számos rivális szállítási rendszert javasoltak, ám egyikük sem dobta ki az UDP-t a pozíciójából, mint elsődleges választást a VoIP és a video streaming számára. A riválisok listája tartalmazza:

A megbízható felhasználói adatgram protokoll (RUDP), amely Cisco és Microsoft implementációkat tartalmaz.

A Stream Control Transmission Protocol (SCTP), amelyet sikertelenül javasoltak az UDP / RTP / RTCP kombináció helyettesítésére, de soha nem kerültek le a földről.

Ezt a csúnya kiskacsát, az UDP-t nevezték el hattyúnak, a szélessávú és az interaktív alkalmazások varázslatos átalakító képességeinek köszönhetően. Ez a megújult csillag könnyedén tovább siklik az internet vizein.

Milyen átviteli módszereket használ? Látja az UDP csúnya kiskacsa hattyúját? Írja meg tapasztalatait az alábbi Megjegyzés szakaszban.

Összefüggő:
Végső útmutató a TCP / IP-hez
Mi a TCPdump??
A SolarWinds TFTP szerver áttekintése
TFTPD32 TFTP szerver áttekintés

Kép:
Az UDP fejléce Devarshi által az angol Wikibooksban, engedélyezett a CC BY-SA 2.5 alapján
A TCI csomag elrendezése bit skálával, Quliyevferman által a Wikimedia Commons segítségével. A CC BY-SA 4.0 alatt engedélyezett