nemrég A Google bemutatta egy új API bevezetését "Nyers aljzatok" a Chrome q-banamely lehetővé teszi a webalkalmazások számára a kapcsolatok létrehozását közvetlen hálózati hálózatok a protokollok segítségével TCP és UDP.
Emlékeztetni kell arra, hogy 2015-ben a W3C konzorcium már megpróbálta egységesíteni a "TCP és UDP Socket" API-t, de a munkacsoport tagjai nem jutottak konszenzusra, és ennek az API-nak a fejlesztését leállították.
De A Google visszatért a sínre mielőtt új API-t kell hozzáadni és az eszközökkel való interoperabilitás biztosításának köszönhető hálózat saját protokollok használatával amelyek TCP-n és UDP-n futnak, és nem támogatják a HTTPS vagy a WebSockets kommunikációt.
Meg kell jegyezni, hogy az API A Raw Sockets kiegészíti a WebUSB, a WebMIDI és a WebBluetooth API-kat alacsony szintű már elérhető a böngészőben, lehetővé téve a helyi eszközökkel való interakciót.
A biztonságra gyakorolt negatív hatás kizárása érdekében a Raw Sockets API csak a felhasználó beleegyezésével indított hálózati hívásokat engedélyezi és csak a felhasználó által engedélyezett hosztok listájára korlátozódik.
A felhasználónak kifejezetten meg kell erősítenie az első kapcsolódási kísérletet az új házigazda számára. Egy speciális zászló segítségével a felhasználó letilthatja a művelet megerősítésére vonatkozó ismételt kérések kimenetét ugyanazon gazdagéphez kapcsolódó ismételt kapcsolatok esetén.
A DDoS támadások elkerülése érdekében a kérések intenzitása a Raw Sockets-on keresztül korlátozott lesz, és a kérelmek elküldése csak a felhasználó interakciója után lehetséges. A A felhasználó által nem jóváhagyott gazdagépektől kapott UDP csomagok figyelmen kívül maradnak, és nem fogják elérni a webalkalmazást.
A kezdeti megvalósítás nem rendelkezik hallgatói foglalatok létrehozásáról, de a jövőben lehetőség van hívások kezdeményezésére a localhost bejövő kapcsolatainak vagy az ismert gazdagépek listájának elfogadására.
Azt is megemlíti, hogy védeni kell a DNS újraindító támadásait (a támadó megváltoztathatja a felhasználó által jóváhagyott tartománynév IP-címét a DNS szintjén, és hozzáférést nyerhet más gazdagépekhez).
A tervek szerint blokkolni kell a hozzáférést a 127.0.0.0/8 verzióban megoldott tartományokhoz és az intranethez a hálózatról (javasoljuk, hogy csak akkor engedélyezzék a localhost hívásait, ha az IP-címet kifejezetten megadják a megerősítő űrlapon).
Az új API bevezetésekor felmerülő kockázatok közül meg kell jegyezni, hogy más böngészők gyártói elutasíthatják ezt, ami kompatibilitási problémákhoz vezethet.
A Mozilla Gecko és a WebKit motorok fejlesztői még nem határozták meg álláspontjukat a Raw Sockets API lehetséges megvalósításával kapcsolatban, de a Mozilla korábban már ajánlott hasonló API-t a Firefox OS (B2G) projekthez.
Ha az első szakaszban jóváhagyják, a Raw Sockets API-t a tervek szerint aktiválni kell a Chrome OS-en, és csak ezután kínálják fel más rendszerek Chrome-felhasználóinak.
Webfejlesztők kedvezően nyilatkoztak az új API-ról és sok új ötlettel álltak elő azokon a területeken, ahol az API-k használhatók Az XMLHttpRequest, a WebSocket és a WebRTC nem elegendő (az SSH, RDP, IMAP, SMTP, IRC böngésző kliensek létrehozásától és a protokollok nyomtatásától kezdve az elosztott P2P rendszerek DHT-vel (Distributed Hash Table), IPFS támogatásáig és az eszközspecifikus IoT protokollokkal való interakcióig) .
Sőt, azt is érdemes megemlíteni A regisztráció APNIC felelős az IP-címek terjesztéséért az ázsiai-csendes-óceáni térségben közzétette a forgalomeloszlás elemzésének eredményeit az egyik DNS-kiszolgálón root-servers.net.
Amelyben a kérelmek 45,80% -a a gyökérkiszolgálóra történő ellenőrzés miatt böngészők készítik a Chromium motor alapján. ezért a root DNS-kiszolgálók erőforrásainak majdnem a fele Chromium diagnosztikai ellenőrzések végrehajtására fordítják őket, nem pedig a DNS-kiszolgáló lekérdezéseinek feldolgozására a gyökérzónák meghatározásakor.
Mivel a Chrome a webböngésző piac 70% -át teszi ki, ez a diagnosztikai tevékenység naponta körülbelül 60 milliárd kérést generál.
A Chromium diagnosztikai ellenőrzéseket használ annak meghatározása, hogy a szolgáltatók olyan szolgáltatókat vesznek-e igénybe, amelyek nem létező nevek iránti kérelmeket irányítanak irányítóikhoz.
Néhány szolgáltató ilyen rendszereket vezet be a forgalom irányítására hibásan beírt domain nevekhez; Az oldalak általában hibajelzéssel, a valószínűleg helyes nevek listájával és a nem létező domainek hirdetéseivel jelennek meg.