Pitanja za razgovor o računarskim mrežama, 63 pitanja o računarskim mrežama (22.000 reči, 80 ručno crtanih crteža), obavezno čitanje za povratak intervjua👍
22.000 reči, 80 ručno crtanih crteža, detaljno objašnjeno 63 čestih pitanja za razgovor o računarskim mrežama (da nema teških pitanja za pamćenje), nakon što naučite ova pitanja o računarskim mrežama, ovaj put ćete impresionirati intervjutora, mislim da je sigurno (ručni pas). Organizirao: Chenmo Wang Er, kliknite na link preuzimanja, autor: Sanfen Er, kliknite na link originalnog teksta.
, danas nastavljam da delim sa vama Sanfen Er-ov povratak intervjua!
Ovaj put donosim 63 pitanja o računarskim mrežama, 30.000 reči, 70 slika detaljnih objašnjenja, verovatno najkompletnija zbirka pitanja za razgovor o računarskim mrežama na internetu.
Preporučujem da sačuvate ovaj tekst da polako čitate, za jesenji regrutaciju, prolećnu regrutaciju, zlatni septembar i oktobar, zlatni mart i april, napred!
Osnove
1.Kažite nešto o arhitekturi računarskih mreža
Arhitektura računarskih mreža standardizuje proces interakcije razlažući kompleksnu mrežnu komunikaciju na slojeve. Uobičajeni modeli uključuju OSI model sa sedam slojeva, TCP/IP model sa četiri sloja i arhitekturu sa pet slojeva.

OSI je teorijski model mrežne komunikacije, TCP/IP je model mrežne komunikacije na nivou praktične primene, arhitektura sa pet slojeva služi za lakše razumevanje i pamćenje.
Kažite nešto o OSI modelu sa sedam slojeva?
OSI (Open System Interconnection) referentni model sa sedam slojeva je model mrežne arhitekture koji je predložila Međunarodna organizacija za standardizaciju (ISO) da opiše i standardizuje funkcije i procese raznih računarskih mreža. Ovih sedam slojeva, od višeg ka nižem, su:
- Sloj aplikacije: Najbliži korisniku, zadužen za rukovođenje specifičnim detaljima aplikacija. Ovaj sloj pruža interfejs između mrežnih servisa i korisničkog softvera. Na primer, Web pretraživači, FTP klijenti i serveri, klijenti e-pošte itd.
- Sloj prezentacije: Osigurava da informacije poslate sa jednog sistema mogu biti pročitane od strane sloja aplikacije drugog sistema. Zadužen je za konverziju, kompresiju i enkripciju podataka. Na primer, osigurava konverziju podataka iz jednog kodiranja u drugo, kao što je ASCII u EBCDIC.
- Sloj sesije: Upravlja sesijama korisnika, kontroliše dijalog između dva čvora na mreži i razmenu podataka. Zadužen je za uspostavljanje, održavanje i prekid sesija. Na primer, uspostavljanje tokena sesije kako bi se omogućilo prenos podataka između dva čvora na mreži.
- Transportni sloj: Pruža servise komunikacije od kraja do kraja, osigurava integritet i ispravan redosled podataka. Ovaj sloj uključuje TCP i UDP.
- Mrežni sloj: Zadužen za prenos podataka između više mreža, osigurava da podaci mogu da pronađu najbolju putanju iz izvora do odredišta u kompleksnoj mrežnoj strukturi. Ovaj sloj koristi IP (Internet Protocol) protokol.
- Sloj veze podataka: Pruža pouznan prenos na fizičkoj vezi, zadužen za uspostavljanje i održavanje veze između dva susedna čvora. Uključuje sinhronizaciju okvira, MAC (Media Access Control).
- Fizički sloj: Zadužen za prenos originalnih podataka preko fizičkih medija, kao što su kablovi, optička vlakna i bežični signali. Uključeni sadržaj uključuje napon, interfejse, pinove, specifikacije kablova i brzine prenosa.
Kažite nešto o TCP/IP modelu sa četiri sloja?
TCP/IP model sa četiri sloja je srce internetske komunikacije, definiše seriju protokola i standarda kako bi osigurao pouzdan prenos podataka između uređaja.

①,Sloj aplikacije: Direktno orijentisan ka korisniku i aplikacijama, pruža razne mrežne servise. Uključuje protokole i servise za specifične aplikacije, kao što su HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol) itd.
Primer: Kada u pretraživaču unesete URL i posetite veb stranicu, pretraživač koristi HTTP protokol da zatraži sadržaj stranice sa veb servera.
②,Transportni sloj: Pruža servise komunikacije od kraja do kraja, osigurava pouzdan prenos podataka. Zadužen je za segmentaciju podataka, kontrolu toka, detekciju i korekciju grešaka. Uobičajeni transportni protokoli su TCP i UDP.
Primer: Kada šaljete e-poruku, TCP protokol osigurava da se e-poruka pouzdano prenese sa vašeg klijenta na server e-pošte.
③,Sloj interneta (Internet Layer): Ili mrežni sloj, zadužen za rutiranje paketa podataka između različitih mreža, pruža logičke adrese (IP adrese) i funkcije mrežnog adresiranja. Koristi se za grupisanje, prosleđivanje i izbor rute paketa podataka, osiguravajući da se podaci mogu preneti sa izvornog na ciljni uređaj.
Uobičajeni protokoli: IPv4, IPv6, ICMP (Internet Control Message Protocol).
Primer: Kada posetite veb sajt, mrežni protokol (kao što je IPv4) prenosi vaš zahtev sa vašeg računara kroz više rutera do ciljnog servera.
④,Sloj mrežnog pristupa (Network Access Layer): Ili sloj veze, zadužen za tačan prenos digitalnih signala kroz fizičke kanale (mrežni kablovi), definiše kako se podaci prenose na jednoj mrežnoj vezi, kako se obrađuje slanje i primanje okvira podataka, uključujući rezoluciju fizičkih adresa (MAC adresa).
Uobičajeni protokoli: Ethernet, Wi-Fi.
Primer: U lokalnoj mreži (LAN), računari su povezani sa prekidačem putem etherneta, protokol sloja veze je zadužen za prenos okvira podataka između mrežnih uređaja.
Kažite nešto o arhitekturi sa pet slojeva?
To je kompromis između OSI i TCP/IP, zadržava praktičnost TCP/IP-a, dok pruža detaljniju podelu od modela sa četiri sloja, olakšavajući nastavu i razumevanje različitih aspekata mreže.
- Sloj aplikacije: Kao interfejs između mrežnih servisa i krajnjeg korisnika. Pruža seriju protokola koje aplikacije mogu da koriste, kao što su HTTP (veb), FTP (prenos datoteka), SMTP (prenos e-pošte) itd. Omogućuje aplikacijama korisnika da pristupe mrežnim servisima.
- Transportni sloj: Pruža upravljanje komunikacijom od procesa do procesa, ovaj sloj osigurava da se podaci prenose uređeno, bez grešaka. Glavni protokoli uključuju TCP i UDP.
- Mrežni sloj: Zadužen za prenos i rutiranje paketa podataka iz izvora do odredišta, uključujući prelazak preko više mreža (tj. interneta). Koristi logičke adrese (kao IP adrese) za jedinstvenu identifikaciju uređaja. Ruteri su uređaji mrežnog sloja.
- Sloj veze podataka: Osigurava pouzdan i efikasan prenos podataka sa jednog čvora na drugi. Prekidači i mostovi su uređaji sloja veze podataka.
- Fizički sloj: Kablovi, optička vlakna, radio frekvencije, mrežni adapteri itd.
Na kom sloju rade TCP trostrano rukovanje i četverostrano rukovanje?
Trostrano i četverostrano rukovanje rade na transportnom sloju. Transportni sloj je četvrti sloj OSI modela, zadužen za pružanje servisa komunikacije od kraja do kraja, uključujući uspostavljanje, održavanje i prekid prenosa podataka.
TCP kao protokol orijentisan na vezu uspostavlja vezu putem trostrukog rukovanja i prekidaje putem četvorostrukog rukovanja, osiguravajući pouzdanost i integritet prenosa podataka.
Objasnite računarske mreže?
Računarske mreže se odnose na sisteme koji povezuju više računara putem komunikacionih uređaja kako bi se omogućilo deljenje resursa i prenos informacija.

- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua Huawei OD kandidata 1: Kažite nešto o OSI referentnom modelu sa sedam slojeva
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog intervjua backend razvoja kandidata 2 kompanije JD: Trostrano rukovanje i četvorostrano rukovanje TCP protokola na kom sloju rade?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 5 kompanije JD za Java backend: Neka kažete nešto o mreži
2.Kažite koji protokoli odgovaraju svakom sloju?
Tabela summarizes uobičajene mrežne protokole:

3.Zašto se podaci prenose između slojeva?
Za pošiljaoca, od višeg sloja ka nižem, svaki sloj dodaje omot, za primaoca, od nižeg sloja ka višem, svaki sloj skida omot.
- Proces aplikacije pošiljaoca šalje podatke procesu aplikacije primaoca
- AP prvo daje podatke sloju aplikacije domaćina, sloj aplikacije doda kontrolne informacije H5 ovog sloja i postaje data jedinica sledećeg sloja
- Transportni sloj prima ovu data jedinicu, doda kontrolne informacije H4 ovog sloja, zatim je daje mrežnom sloju, postajući data jedinica mrežnog sloja
- Na sloju veze podataka, kontrolne informace se dele u dva dela, dodate na početak (H2) i kraj (T2) data jedinice ovog sloja
- Konačno, fizički sloj vrši prenos bit streama

Ovaj proces je sličan pisanju pisma, svaki sloj dodaje kovertu i adrese. Kada stigne do odredišta, sloj po sloj se skida i šalje na sledeće odredište.
GitHub open-soursna baza znanja sa preko 17.000 zvezdica "Ergov put napredovanja u Javi" prvo izdanje PDF konačno je stiglo! Uključuje osnovnu Java sintaksu, nizove&stringove, OOP, kolekcione okvire, Java IO, rukovanje izuzecima, nove Java osobine, mrežno programiranje, NIO, konkurentno programiranje, JVM itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Fantastično, Java tutorijal sa preko 17.000 zvezdica na GitHubu
Mrežni pregled
4.Kako proces ulaska URL-a u adresnu traku pretraživača do prikazivanja veb stranice?
Ovaj proces uključuje više koraka, pokrivajući DNS rezoluciju, TCP vezu, slanje HTTP zahteva, server obradu zahteva i vraćanje HTTP odgovora, pretraživač obradu odgovora i renderovanje stranice itd.
- DNS rezolucija: Pretraživać će poslati DNS zahtev na DNS server da pretomi domenu u IP adresu servera.
- TCP veza: Pretraživać uspostavlja TCP vezu sa serverom putem IP adrese dobijene rezolucijom. Ovaj korak uključuje trostruko rukovanje TCP protokola da bi se osiguralo da su obe strane spremne za prenos podataka.
- Slanje HTTP zahteva: Pretraživać gradi HTTP zahtev, uključujući liniju zahteva, zaglavlje i telo zahteva, zatim šalje zahtev na server.
- Server obrada zahteva: Server prima HTTP zahtev, prema putanji resursa zahteva, nakon backend obrade generiše HTTP odgovor, odgovor uključuje status liniju, zaglavlje odgovora i telo odgovora.
- Pretraživać prima HTTP odgovor: Pretraživać počinje da analizira HTML sadržaj u telu odgovora nakon što prima HTTP odgovor od servera, zatim gradi DOM stablo, analizira CSS i JavaScript fajlove itd., konačno renderuje stranicu.
- Prekid veze: Četvorostruko rukovanje TCP protokola, veza se završava.
Uzmimo kao primer unos www.baidu.com:

Koji protokoli se koriste u svakom procesu?

- Vodič za razgovor o Javi (plaćeno) uključuje originalno pitanje prvog intervjua komercijalizacije ByteDance: Kompletan proces URL zahteva (detaljno)
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 9 kompanije ByteDance za Feishu backend: Šta se dešava kada se unese URL
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 8 kompanije ByteDance za Java backend stažiranje: Kompletan proces unosa URL adrese u pretraživač
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 19 kompanije ByteDance za Tomato Novel: Proces unosa URL do prikazivanja stranice
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 2 kompanije Li Auto: Proces unosa www.baidu.com u pretraživač do prikazivanja
5.Kažite nešto o procesu DNS rezolucije?
DNS puno ime je Domain Name System, to je sistem za rezoluciju domena, može da mapira domen u odgovarajuću IP adresu, na primer kada pristupamo www.javasi.dev, zapravo pristupamo jeftinom serveru na Aliyun-u, njegova IP adresa je xxx.xxx.xxx.xxx.
Naravno, može se direktno pristupiti serveru putem IP adrese, ali to nije pogodno za pamćenje, zato postoji sistem domena. Dobar domen može da se skupo proda, kao domen javasi.dev, košta 39 yuna godišnje.
Mapiranje domena u IP adresu zahteva DNS.

Kažite nešto o procesu DNS rezolucije:

Pretpostavimo da smo u adresnoj traci pretraživača uneli paicoding.com:
Pretraživać će prvo proveriti sopstveni keš da li postoji IP adresa koja odgovara ovoj domeni, ako postoji, direktno vraća, ako ne, ulazi u sledeći korak.

Proveriti da li u lokalnom DNS kešu postoji zapis o ovoj domeni. Ako ne, šalje zahtev root DNS serveru, root DNS server usmerava zahtev na specifičniji servis, kao što je com top-level domen server.
Top-level domen server zatim usmerava zahtev na autoritativni domen server, obično direktno upravljan od strane registra domena, paicoding.com je registrovan na Aliyun-u, zato Aliyun pruža odgovarajuću DNS rezoluciju, vezujući domen za Aliyun server.
Konačno, pretraživać koristi dobijenu IP adresu da pošalje HTTP zahtev na ciljni server, zatim server vraća traženi sadržaj veb stranice.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 6 kompanije Huawei za Java opšti razvoj softvera: Kažite nešto o procesu DNS rezolucije
6.Kažite koja je razlika između WebSoketa i Soketa?
- Soket je zapravo jednak IP adresa + port + protokol.
Konkretno, Soket je standard, kompletira visoku enkapsulaciju TCP/IP-a, sakriva mrežne detalje kako bi programerima olakšao mrežno programiranje.
- WebSocket je trajni protokol, dolazi uz HTML5, rešava problem http ne podržava trajne veze.
- Soket je standardni interfejs mrežnog programiranja, dok je WebSocket aplikacioni komunikacioni protokol.
7.Kažite nešto o portovima i odgovarajućim servisima koje poznajete?

8.Da li koristite alatke za praćenje paketa (dopuna)?
Dodato 25. decembra 2024. godine
Ja najviše koristim mrežni panel ugrađen u Chrome pretraživač, mogu videti vreme zahteva, informacije o zahtevu i informacije o odgovoru.

Profesionalniji alati uključuju Fiddler, Wireshark itd.

- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 30 kompanije Tencent Music: Koju alatku obično koristite za praćenje paketa.
GitHub open-sorsna baza znanja sa preko 17.000 zvezdica "Ergov put napredovanja u Javi" prvo izdanje PDF konačno je stiglo! Uključuje osnovnu Java sintaksu, nizove&stringove, OOP, kolekcione okvire, Java IO, rukovanje izuzecima, nove Java osobine, mrežno programiranje, NIO, konkurentno programiranje, JVM itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Fantastično, Java tutorijal sa preko 17.000 zvezdica na GitHubu
HTTP
9.Kažite nešto o uobičajenim status kodovima HTTP i njihovim značenjima?
HTTP status kodovi se koriste da označe rezultat servera u obradi zahteva, mogu se podeliti u 5 vrsta:
- 1xx Server je primio zahtev, treba dodatne operacije, na primer 100 Continue.
- 2xx Zahtev je uspešno obrađen, na primer 200 OK.
- 3xx Redirekcija: potrebne su dodatne operacije za completanje zahteva, na primer 304 Not Modified znači da resurs nije promenjen, klijent može koristiti keš.
- 4xx Greška klijenta: problem sa zahtevom, na primer 404 Not Found znači da resurs ne postoji.
- 5xx Greška servera, na primer 500 Internal Server Error znači internu grešku servera.

Kažite koja je razlika između 301 i 302?
- 301: Trajno premeštanje, zahtevani resurs je trajno premešten na novu lokaciju. Server vraća novu adresu resursa kada vrati ovaj odgovor.
- 302: Privremeno premeštanje, server vraća resurs sa druge adrese, ali klijent treba i dalje koristiti ovu adresu.
Metaforom, 301 je venčana Yui Aragaki, 302 je devojka sa dečkom Masami Nagasawa.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog intervjua kandidata 13 kompanije ByteDance za Java backend: Koji su odgovori na HTTP zahteve
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 27 kompanije Tencent za cloud backend: HTTP status kodovi
10.Koje načine zahteva ima HTTP?
HTTP protokol definiše više načina zahteva, indicirajući svrhu zahteva. Uobičajeni načini zahteva su GET, POST, DELETE, PUT.

- GET: Zahteva preuzimanje specificiranog resursa. Treba koristiti samo za uzimanje podataka, i idempotentno je, to jest višestruko izvršavanje istog GET zahteva treba da vrati isti rezultat, neće promeniti stanje resursa.
- POST: Šalje podatke na specificirani resurs, traži od servera da obradi (kao što je podnošenje forme ili otpremanje fajlova). Podaci se nalaze u telu zahteva. Može kreirati nove resurse ili modifikovati postojeće.
- DELETE: Briše specificirani resurs.
- PUT: Koristi se za zamenu specificiranog resursa. Ako specificirani resurs ne postoji, kreira novi resurs.
- HEAD: Slično GET zahtevu, osim što u vraćenom odgovoru nema konkretnog sadržaja, koristi se za uzimanje zaglavlja. Može se koristiti za proveru postojanja resursa, verifikaciju vreme ažuriranja resursa itd.
- OPTIONS: Koristi se za dobijanje HTTP metoda koje server podržava. Obično se koristi u pre-flight zahtevima (CORS) za ukršteni zahtev.
- TRACE: Vraća zahtev koji je server primio, uglavnom se koristi za testiranje ili dijagnostiku. Ali zbog sigurnosnih rizika (može otkriti osetljive informacije), mnogi serveri će onemogućiti TRACE zahtev.
- CONNECT: Uspostavlja tunel do ciljnog resursa (obično se koristi za SSL/TLS proksi), koristi se za enkriptovan prenos tunela između klijenta i servera.
Može li HTTP GET metoda da izvrši operacije upisa?
Može, ali se ne preporučuje.
Korišćenje GET za izvršavanje operacija upisa može dovesti do ozbiljnih sigurnosnih problema, kao što je CSRF (Cross-Site Request Forgery).
U stvarnom razvoju, treba eliminisati korišćenje GET metode za izvršavanje operacija upisa. U projektu Tehnical Pai, eksplicitno ćemo definisati koji metod zahteva treba koristiti na interfejsu.

Ako klijent pogrešno koristi ❎, dobiće odgovor 405 Method Not Allowed.
Šta je idempotentnost? Koje su idempotentne metode?
Idempotentnost je matematički koncept, koristi se za opis karakteristika određenih operacija, to jest bez obzira koliko puta se operacija izvrši, rezultat je isti. Drugim rečima, idempotentne operacije mogu se ponavljati bez promene stanja sistema.
Ako je operacija idempotentna, onda je efekat izvršavanja te operacije jednom isti kao efekat izvršavanja više puta na istom resursu.
U ispravno implementiranim uslovima, GET, HEAD, PUT i DELETE metode su idempotentne, dok POST metoda nije.
Na primer, GET /pageX HTTP/1.1 je idempotentna. Kontinuirano pozivanje više puta, rezultat koji klijent prima je isti:
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1DELETE /idX/delete HTTP/1.1 je idempotentna, čak iako se status kodovi koji se primaju između različitih zahteva razlikuju:
DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1 -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1 -> Returns 404
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog tehničkog intervjua kandidata 13 kompanije ByteDance za Java backend: koje metode ima http, da li http get metoda može izvršiti operacije upisa, da li je https url prenos bezbedan, šta je napad u sredini
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog tehničkog intervjua kandidata 1 kompanije ByteDance: Šta je idempotentnost? Koje idempotentne metode poznajete?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua uživo kandidata 3 kompanije Sangfor za Java backend: Sve http metode osim get post.
11.Kažite koja je razlika između GET i POST?

GET zahtev se uglavnom koristi za uzimanje podataka, parametri se dodaju u URL, postoji ograničenje dužine, lako se kešira od strane pretraživača, ima sigurnosne rizike, dok POST zahtev služi za slanje podataka, parametri se stavljaju u telo zahteva, pogodan za slanje velikih količina ili osetljivih podataka.
Dodatno, GET zahtev je idempotentan, višestruki zahtevi neće promeniti stanje servera, dok POST zahtev nije idempotentan, može uticati na podatke na serveru.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 8 kompanije JD: get i post zahtevi
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje tehničkog intervjua kandidata 17 kompanije ByteDance: Koja je razlika između get i post
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 13 kompanije Shopee: Koja je razlika između http get i post
12.Koja je ograničenja dužine GET zahteva?
HTTP GET metoda prenosi podatke putem URL-a, ali URL zapravo ne ograničava dužinu podataka, stvarno ograničenje dužine GET-a dolazi od pretraživača.
Na primer, pretraživač IE ima maksimalno ograničenje od oko 2000 karaktera za URL, otprilike 2KB, dok pretraživači kao što su Chrome i Firefox podržavaju više karaktera URL-a, gde je maksimalna dužina URL-a u FireFox-u 65536 karaktera, a u Chrome-u 8182 karaktera.
Ovo ograničenje dužine se odnosi na ceo URL, ne samo na deo sa podacima.
13.Koji su proces i princip HTTP zahteva?
HTTP je aplikacioni sloj protokol baziran na TCP/IP protokolu, koristi TCP kao transportni protokol, prenosi podatke uspostavljanjem TCP veze.
HTTP prati standardni klijent-server model, klijent otvara vezu i šalje zahtev, zatim čeka odgovor servera.

- Nakon unosa URL-a u pretraživač, pretraživać prvo dobija IP adresu servera putem DNS rezolucije, zatim uspostavlja TCP vezu sa serverom.
- Nakon uspostavljanja TCP veze, pretraživać šalje HTTP zahtev na server.
- Server primi zahtev, obrađuje zahtev prema informacijama u zahtevu.
- Nakon obrade zahteva, server vraća HTTP odgovor pretraživaču.
- Pretraživač primi odgovor, renderuje stranicu prema informacijama u odgovoru. Zatim, pretraživač i server prekidaju TCP vezu.
Klijent šalje zahtev na server, server obrađuje zahtev i vraća odgovor. Ovaj proces je sinhron, to jest klijent mora čekati odgovor servera nakon slanja zahteva. U procesu čekanja odgovora, klijent ne šalje druge zahteve.
Kako koristiti više niti za preuzimanje jednog podatka?
Može se koristiti strategija deljenog preuzimanja. Prvo, dobija se ukupna veličina fajla putem HEAD zahteva. Zatim se, prema veličini fajla i broju niti, fajl deli. Svaka nit je zadužena za preuzimanje specificiranog opsega podataka.
Može se specificirati bajt opseg za preuzimanje postavljanjem Range polja u zaglavlju HTTP zahteva. Na primer, Range: bytes=0-1023 znači preuzimanje prvih 1024 bajtova fajla.
Konačno, pokreće se preuzimanje sa više niti.
Kodni fragment 1: Dobijanje veličine fajla
URL url = new URL("https://javasi.dev/file.zip");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("HEAD");
int fileSize = connection.getContentLength(); // Dobijanje veličine fajla
connection.disconnect();Kodni fragment 2: Preuzimanje fajla
public void downloadChunk(String url, int start, int end, String outputPath) {
try {
URL fileUrl = new URL(url);
HttpURLConnection connection = (HttpURLConnection) fileUrl.openConnection();
connection.setRequestProperty("Range", "bytes=" + start + "-" + end);
InputStream inputStream = connection.getInputStream();
RandomAccessFile file = new RandomAccessFile(outputPath, "rw");
file.seek(start); // Pozicioniranje na odgovarajuću lokaciju u fajlu
byte[] buffer = new byte[1024];
int bytesRead;
while ((bytesRead = inputStream.read(buffer)) != -1) {
file.write(buffer, 0, bytesRead);
}
file.close();
inputStream.close();
connection.disconnect();
} catch (IOException e) {
e.printStackTrace();
}
}Kodni fragment 3: Pokretanje preuzimanja sa više niti
int numThreads = 4;
int fileSize = 100000000; // Pretpostavimo da je veličina fajla 100MB
int chunkSize = fileSize / numThreads;
String url = "https://javasi.dev/file.zip";
String outputPath = "path/to/local/file.zip";
ExecutorService executor = Executors.newFixedThreadPool(numThreads);
for (int i = 0; i < numThreads; i++) {
int start = i * chunkSize;
int end = (i == numThreads - 1) ? fileSize - 1 : (start + chunkSize - 1);
executor.execute(() -> downloadChunk(url, start, end, outputPath));
}
executor.shutdown();PS: Možete jednostavno testirati lokalno.

Ako želite samo preuzeti prvih 10 bajtova podataka?
Samo postavite Range polje na Range: bytes=0-9.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 1 kompanije Huawei OD: Što je HTTP?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 6 kompanije China Merchants Bank: Jedan proces HTTP prenosa zahteva
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 27 kompanije Tencent za cloud backend: Kako HTTP prenosi podatke? Ako koristim više niti za preuzimanje podataka sa interneta, kako da preuzmem? Ako želim samo preuzeti prvih 10 bajtova podataka?
14.Kažite nešto o strukturi HTTP poruka?
Struktura HTTP poruka je podeljena na: zahtevnu poruku i odgovornu poruku. Obe su slične po strukturi, obe sadrže početnu liniju, zaglavlje i telo poruke.

Kažite nešto o strukturi HTTP zahtevne poruke?
Zahtevna poruka se sastoji od linije zahteva, zaglavlja zahteva, prazne linije i tela poruke. Kao što je prikazano:
GET /index.html HTTP/1.1
Host: www.javasi.dev
Accept: text/html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3①,Linija zahteva uključuje metod zahteva, URL zahteva i verziju HTTP protokola. Na primer: GET /index.html HTTP/1.1.
②,Zaglavlje zahteva sadrži dodatne informacije o zahtevu, kao što je tip sadržaja koji klijent želi da primi, tip pretraživača itd. Na primer:
Host: www.javasi.dev, označava ime hosta (domen) zahtevaAccept: text/html, označava tip medija koji klijent može primitiUser-Agent: Mozilla/5.0, označava tip pretraživača klijenta- Range: Koristi se za specificiranje opsega sadržaja zahteva, kao bajt opseg pri nastavku preuzimanja.
③,Između zaglavlja zahteva i tela poruke postoji prazna linija, koja označava kraj zaglavlja zahteva.
④,Telo poruke je opcionalno, kao podaci forme u POST zahtevu, u GET zahtevu nema tela poruke.
Kažite nešto o strukturi HTTP odgovorne poruke?
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Chenmo Wang Er je veoma naivan</body>
</html>①,Status linija
Uključuje verziju HTTP protokola, status kod (kao 200, 404) i status poruku (kao OK, NotFound). Na primer: HTTP/1.0 200 OK.
②,Zaglavlje odgovora
Sadrži dodatne informacije o odgovoru, kao tip servera, tip sadržaja, dužinu sadržaja itd. Takođe je u obliku ključ-vrednost, na primer:
Content-Type: text/plain, označava tip sadržaja odgovoraContent-Length: 137582, označava dužinu sadržaja odgovoraExpires: Thu, 05 Dec 1997 16:00:00 GMT, označava vreme isteka resursaLast-Modified: Wed, 5 August 1996 15:55:28 GMT, označava vreme poslednje modifikacije resursaServer: Apache 0.84, označava tip servera
③,Prazna linija
Označava kraj zaglavlja odgovora.
④,Telo poruke (opcionalno)
Konkretni sadržaj odgovora, kao HTML stranica. Ne svi odgovori imaju telo poruke, kao odgovor sa status kodom 204 No Content.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 3 kompanije BYD: Kažite nešto o strukturi HTTP i principu HTTPS
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 3 male kompanije za QA testiranje: Format HTTP zahtevne i odgovorne poruke
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 27 kompanije Tencent za cloud backend: Koja su uobičajena zaglavlja HTTP zahteva?
15.Koja je razlika između URI i URL?

- URI, Uniform Resource Identifier, identifikuje svaki dostupan resurs na vebu, kao HTML dokumente, slike, video isječke, programe itd., svi su identifikovani URI-jem.
- URL, Uniform Resource Location, podskup je URI-a, glavna uloga je da pruži putanju do resursa.
Glavna razlika je u tome što URL pored identifikacije resursa pruža i način pristupa resursu. Metaforom, URI je lična karta, može jedinstveno identifikovati osobu, dok je URL više kao adresa, može se pronaći osoba putem URL-a — protokol adrese čovejeka: zemlja/kina/peking/haidean/distrikt/XX stručna škola/14 zgrada/525 soba/Zhang San.muški.
16.Kažite nešto o razlici između HTTP1.0, 1.1, 2.0?
HTTP1.0 podrazumeva kratku vezu, HTTP 1.1 podrazumeva dugu vezu, HTTP 2.0 koristi multiplexing.

Kažite nešto o HTTP1.0
- Bezstadanjašnji protokol: HTTP 1.0 je bez stanja, svi zahtevi su međusobno nezavisni, server ne čuva nikakve informacije o stanju zahteva.
- Netrajna veza: Podrazumevano, nakon svakog HTTP zahteva/odgovora, veza se zatvara, pripada kratkim vezama. To znači da za svaki zahtev za resurs na istom sajtu, kao slike i skripte na HTML stranici, treba uspostaviti novu TCP vezu. Može se postaviti
Connection: keep-aliveda se forsira otvaranje duge veze.
Kažite nešto o HTTP1.1
- Trajna veza: HTTP 1.1 uvodi trajnu vezu (takođe poznatu kao HTTP keep-alive), podrazumevano neće odmah zatvoriti vezu, može se poslati više zahteva i odgovora na jednoj vezi. Drastično smanjuje troškove TCP veze.
- Pipelining obrada: HTTP 1.1 podržava klijenta da pošalje sledeći zahtev pre nego što primi odgovor na prethodni zahtev, kako bi povećao efikasnost prenosa.
Kažite nešto o HTTP2.0
- Binarni protokol: HTTP 2.0 koristi binarni format umesto tekstualnog za prenos podataka, parsiranje je efikasnije.
- Multiplexing: Više HTTP zahteva/odgovora može istovremeno biti poslato na jednoj TCP vezi, rešava problem head-of-line blokiranja HTTP 1.x.
- Kompresija zaglavlja: HTTP protokol nema stanje, zato svaki zahtev mora nositi sve informacije. HTTP 2.0 uvodi mehanizam kompresije zaglavlja, može koristiti gzip ili compress kompresiju pre slanja, smanjuje potrošnju propusnog pojasa zbog redundancije zaglavlja.
- Server push: Server može aktivno gurati resurse klijentu, bez potrebe da klijent eksplicitno zahteva.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 23 kompanije Tencent za QQ backend tehničko: Razlika između HTTP 1 i 2
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 30 kompanije Tencent Music: Razlika između http2.0 i http1.0
17.Znate li nešto o HTTP/3?
HTTP/2.0 je baziran na TCP protokolu, dok je HTTP/3.0 baziran na QUIC protokolu, Quick UDP Connections, prevodeno kao brze UDP mrežne veze.

Iako je HTTP/2.0 baziran na TCP, sa logičke perspektive, različiti tokovi su međusobno nezavisni, ne utiču jedni na druge, ali u stvarnom procesu prenosa, podaci se ipak šalju i primaju okvir po okvir, jednom kada podaci jednog toka budu izgubljeni, i dalje će blokirati podatke toka koji se šalju posle njega.
QUIC protokol baziran na UDP može rešiti ovaj problem temeljnije, omogućavajući različitim tokovima da se zaista prenose nezavisno, bez međusobnog ometanja.
Istovremeno, QUIC protokol završava TLS enkripciju handsahke u procesu prenosa, direktniji.
Koja verzija HTTP se najviše koristi?
Trebalo bi da bude HTTP/2, dostigao vrhunac u januaru 2022. godine, čini 46,9% svih veb sajtova.
Statistički sajt: w3techs

- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog tehničkog intervjua kandidata 8 kompanije Huawei: Razlika između HTTP 2.0 i 3.0
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog tehničkog intervjua kandidata 1 kompanije ByteDance: Koja verzija HTTP se najviše koristi?
18.Znate li nešto o trajnoj HTTP vezi?
U HTTP-u, trajna veza znači da nakon completiranja jedne HTTP komunikacije između klijenta i servera, veza neće odmah biti prekinuta, već će se zadržati za ponovnu upotrebu za naredne zahteve.
Ovaj mehanizam može smanjiti troškove čestog uspostavljanja i zatvaranja veza.
Kako podesiti trajnu vezu?
Može se postići putem Connection: keep-alive. U HTTP/1.1, trajna veza je podrazumevano uključena.
Kada će isteći?
- HTTP opšte ima httpd demon proces, može se podesiti keep-alive timeout, kada tcp veza bude mirujuća duže od ovog vremena će se zatvoriti, takođe može se podesiti vreme isteka u zaglavlju HTTP-a
- TCP keep-alive sadrži tri parametra, podržava podešavanje u kernelu sistema net.ipv4, nakon uspostavljanja TCP veze, kada miruje duže od tcp_keepalive_time, poslaće se detektni paket, ako ne primi ACK od druge strane, svakih tcp_keepalive_intvl će poslati jedan ponovo, dok se pošalje tcp_keepalive_probes, veza će biti odbačena.
1. tcp_keepalive_intvl = 15
2. tcp_keepalive_probes = 5
3. tcp_keepalive_time = 1800
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 27 kompanije Tencent za cloud backend: Kako HTTP održava trajnu vezu?
19.🌟Kažite koja je razlika između HTTP i HTTPS?
HTTPS je poboljšana verzija HTTP-a, dodaje SSL/TLS protokol na osnovu HTTP-a, osiguravajući da su podaci enkriptovani tokom prenosa.

HTTP podrazumevani port je 80, URL počinje sa http://, HTTPS podrazumevani port je 443, URL počinje sa https://.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog intervjua kandidata 13 kompanije ByteDance za Java backend: razlika između http i https, kako https uspostavlja vezu, da li https koristi simetričnu ili asimetričnu enkripciju
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 3 male kompanije za QA testiranje: Kažite razliku između HTTP i HTTPS
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 19 kompanije ByteDance za Tomato Novel: razlika između https i http, implementacija enkripcije
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 9 kompanije Dewu: Predstavite razliku između http i https? Zašto je https bezbedan?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 30 kompanije Tencent Music: Koja je razlika između http i https? Gde je sigurnost https?
memo: 3. septembra 2025. promenjeno do ovde, danas član planete posla privatnu poruku kaže da je dobio zvaničnu ponudu od JD-a, biznis izgleda vrlo core, zaista treba čestitati 🎉, koliko uložiš toliko dobiješ, pre nego što se procvetne, treba uporno nastaviti, ohrabriti sebe.

20.Zašto koristiti HTTPS?
HTTP prenosi podatke u vidu teksta, postoje problemi kao što su prisluškivanje podataka, menjanje podataka i falsifikovanje identiteta. HTTPS uvodi SSL/TLS da reši ove probleme.
SSL/TLS u procesu enkripcije uključuje dve vrste metoda enkripcije:
- Asimetrična enkripcija: Server šalje javni ključ klijentu, klijent enkriptuje sopstveni nasumični ključ (session key) javnim ključem i šalje ga serveru, server dekritpuje sopstvenim privatnim ključem i dobija session key.
- Simetrična enkripcija: Obje strane koriste session key za enkripciju komunikacionog sadržaja.

Klijent proverava identitet servera putem digitalnog sertifikata, digitalni sertifikat izdaje CA, uključuje javni ključ servera, izdavaoca sertifikata, važnost sertifikata itd.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 3 kompanije BYD: Kažite nešto o strukturi HTTP i principu HTTPS
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 26 kompanije Tencent za letnji stažić na WeChat Pay: enkripcijska tehnologija https
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 3 kompanije Meituan za Java backend: Koja je razlika između https i http, simetrična i asimetrična enkripcija, verifikacija CA sertifikata
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 27 kompanije Tencent za cloud backend: Šta je HTTPS? Koji problem HTTP-a rešava?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 13 kompanije Shopee: Da li ste koristili https kako osiguravate bezbednost
21.Kako HTTPS uspostavlja vezu?
HTTPS veza se uspostavlja na osnovu SSL/TLS handsahkea, proces se može podeliti u dve faze: faza handsahkea i faza prenosa podataka.

①,Klijent šalje zahtev na server
②,Server primi zahtev, vraća sopstveni digitalni sertifikat, uključujući javni ključ, izdavaoca itd.
③,Klijent primi sertifikat servera, proveri legitimnost sertifikata, ako je legitimna, generiše nasumični kod, zatim enkriptuje ovaj nasumični kod javnim ključem servera i šalje ga serveru.
④,Server primi session key, dekritpuje ga privatnim ključem i dobija session key.
⑤,Klijent i server enkriptuju komunikacioni sadržaj session key-em, zatim prenose.
Ako se komunikacioni sadržaj presretne, ali jer nema session key, ne može se dekritpovati. Kada se komunikacija završi, veza će se zatvoriti, session key će biti uništen, sledeća komunikacija će ponovo generisati session key.
Da li HTTPS enkriptuje URL?
HTTPS osigurava kroz SSL/TLS protokol da se podaci razmenjeni između klijenta i servera enkriptuju, uključujući HTTP zaglavlje i telo.
A URL je deo HTTP zaglavlja, zato je i ova informacija enkriptovana.

Ali jer uključuje proces SSL handsahkea, informacija o domeni će biti izložena, treba obratiti pažnju.

Dodatno, potpuni URL može biti zabeležen u logovima veb servera, ovi logovi mogu biti u vidu teksta. Takođe, URL je vidljiv u istoriji pretraživača.
Zato, osetljive informacije nikada ne treba slati putem URL-a, čak i kada se koristi HTTPS.
Šta je napad u sredini?
Napad u sredini (Man-in-the-Middle, MITM) je česta mrežna sigurnosna pretnja, napadač može umetnuti sebe između dva kraja komunikacije da bi uzeo informacije obe strane.

U mnogim filmovima postoji scena: glavni lik na neki način maskira kao čovek u sredini, zatim krade informacije komunikacije obe strane, u Mission Impossible films sa Tom Cruise-om postoji mnogo sličnih scena.
Napad u sredini je napad koji nema uzajamnu autentifikaciju, zato mnogi enkripcioni protokoli specijalno dodaju neke specifične metode autentifikacije da bi sprečili napad u sredini. Kao SSL protokol, sprečava napad u sredini proverom digitalnog sertifikata servera, da li je izdalo CA (autoritativno uverenjeno telo za digitalne sertifikate).
Kako HTTPS osigurava da je kanal bezbedan?
Glavno kroz višeslojni sigurnosni mehanizam SSL/TLS protokola, prvo u fazi handsahkea, klijent i server koriste asimetričnu enkripciju, generisani session key može dekritpovati samo privatni ključ servera, a privatni ključ drži samo server.
U fazi prenosa podataka, čak i ako napadač presretne komunikacione podatke, bez session key ne može dekritpovati.
Da li se može pratiti HTTPS saobraćaj?
Može, HTTPS saobraćaj može se pratiti, ali jer je komunikacioni sadržaj enkriptovan, mora se dekritpovati da bi se videlo.

Princip je kroz čoveka u sredini, falsifikovati sertifikat servera i dobiti poverenje klijenta, zatim proslediti zahtev klijenta na server i odgovor servera klijentu, completirati napad u sredini.
Uobičajeni alati za praćenje uključuju Wireshark, Fiddler, Charles itd.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog intervjua kandidata 13 kompanije ByteDance za Java backend: razlika između http i https, kako https uspostavlja vezu, da li https koristi simetričnu ili asimetričnu enkripciju
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog tehničkog intervjua kandidata 13 kompanije ByteDance za Java backend: koje metode ima http, da li http get metoda može izvršiti operacije upisa, da li je https url prenos bezbedan, šta je napad u sredini
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 27 kompanije Tencent za cloud backend: Kako https uspostavlja vezu? Kako https osigurava da je kanal bezbedan?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 13 kompanije Shopee: Da li se može pratiti https
memo: 20. septembra 2025. promenjeno do ovde, danas član planete poslao dobru vest kaže da je dobio ponudu od Midea-a, iako nije velika kompanija, ali se oseća vrlo srećno, i posebno me je zahvalio na podršci. Sa sigurnosnom mrežom se može neustrašivo nastaviti napred.

22.Kako klijent proverava legitimnost sertifikata?
Preporučeno čitanje: U procesu HTTPS handsahkea, kako klijent proverava legitimnost sertifikata
Prvo, svi sertifikati izdaju CA organizacije, CA organizacija je uverenjena treća strana, vrši verifikaciju identiteta aplikanta sertifikata, zatim izdaje sertifikat.
CA je kao javni bezbednosni biro u mrežnom svetu, ima izuzetno visok stepen poverenja.

Proces izdavanja sertifikata od strane CA je vrlo strogi:
- Prvo, CA će spremiti javni ključ, namenu, izdavaoca, važnost i druge informacije u paket, zatim izvršiti Hash proračun na ovim informacijama, dobija Hash vrednost,
- Zatim će CA koristiti sopstveni privatni ključ da enkriptuje tu Hash vrednost, generiše Certificate Signature,
- Konačno, Certificate Signature se doda na sertifikat, formira digitalni sertifikat.

Klijent (obično pretraživač, obično ugrađuje javni ključ informacije CA) pri proveri legitimnosti sertifikata, glavno kroz sledeće korake da proveri legitimnost sertifikata.
- Pretraživać će pročitati vlasnika, važnost, izdavaoca i druge informacije sertifikata, prvo proveriti da li se domen poklapa, zatim proveriti da li je istekla važnost sertifikata,
- Pretraživać počne da traži ugrađenu CA, upoređuje sa izdavačem u sertifikatu koji je vratio server, potvrđuje da li je legitimna organizacija,
- Ako jeste, dekritpuje Signature sadržaj Certificate ugrađenim javnim ključem CA, dobija Hash vrednost H2,
- Koristi isti Hash algoritam da dobije Hash vrednost H1 sertifikata, upoređuje H1 i H2, ako su vrednosti iste, tada je to poverljiv sertifikat, inače upozorava.
Ako u procesu HTTPS komunikacije, čovek u sredini falsifikuje sertifikat, ali jer nema privatni ključ CA organizacije, ne može generisati ispravan Signature, zato ne može proći proveru.
Ako server pošalje klijentu enkripcijski algoritam koji klijent nema, šta će se desiti?
Ako klijent ne podržava nijedan enkripcijski algoritam koji server predlaže, sigurna veza neće biti uspostavljena.
Kada klijent šalje HTTPS zahtev na server, šalje ClientHello poruku.

Ova poruka uključuje listu enkripcijskih algoritama koje klijent podržava (tzv. cipher suites), i druge parametre.
Server primi ClientHello, bira cipher suite koji takođe podržava iz liste koju je klijent ponudio, i vraća klijentu u ServerHello poruci.

Ako server ne može pronaći cipher suite koji obe strane podržavaju, poslaće upozorenje, znači da nije moguće dogovoriti zajednički enkripcijski algoritam, zatim će veza biti prekinuta.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 1 kompanije Dewu: HTTPS, šta raditi sa falsifikovanim sertifikatom čoveka u sredini, falsifikovana organizacija sertifikata
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 34 kompanije ByteDance za Java backend: Kako klijent proverava legitimnost CA sertifikata
24.Kako razumeti da je HTTP protokol bez stanja?
HTTP protokol je bez stanja, to znači da je svaki HTTP zahtev nezavisan, server ne čuva nikakve istorijske informacije o zahtevima klijenta.
Drugim rečima, moja vrata su uvek otvorena, dobrodošli svi, ne mari, samo platite, oh ne, po pravilima, sve je lako.
- Svaki HTTP zahtev sadrži sve neophodne informacije, server pri obradi trenutnog zahteva ne zavisi od nikakvih informacija o prethodnim zahtevima.
- Server ne beleži nikakvo stanje zahteva klijenta, svaki zahtev je kao prva komunikacija sa serverom.
Budući da je HTTP bez stanja, stanje korpinke korisnika mora biti održavano na druge načine, kao što je slanje ID-a korisnika u svakom zahtevu, ili korišćenje Cookie-a na klijentu da čuva stanje korpinke.
Koje su metode za čuvanje stanja?
- Cookies: Server čuva informacije o stanju na klijentu putem Set-Cookie odgovornog zaglavlja, klijent šalje ovaj Cookie u narednim zahtevima da održi stanje.
- Session: Server generiše jedinstveni ID sesije, čuva u Cookie-u, i održava informacije o stanju povezane sa ovim ID sesije na serveru.
- Token: Koristi mehanizam kao JWT (JSON Web Token) da čuva informacije o stanju na klijentu, klijent šalje ovaj Token u svakom zahtevu.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 8 kompanije ByteDance za Java backend stažiranje: Zašto je http bez stanja
25.Koja je veza i razlika između Session i Cookie?
Prvo pogledajmo šta su Session i Cookie:
- Cookie je mali deo teksta datoteka čuvan na klijentu. Kada klijent šalje zahtev na server, server će poslati Cookie klijentu, klijent čuva Cookie. Kada klijent sledeći put šalje zahtev na isti server, Cookie se šalje zajedno sa serverom. Server može suditi o identitetu i stanju korisnika na osnovu ovog Cookie-a.
- Session se odnosi na proces jedne sesije između servera i klijenta. To je drugi mehanizam za čuvanje stanja klijenta. Razlika je u tome što se Cookie čuva u pretraživaču klijenta, dok se session čuva na serveru. Kada pretraživač klijenta pristupa serveru, server čuva informacije o klijentu u određenom obliku na serveru, to je session. Kada pretraživač klijenta sledeći put pristupa, samo treba da pronađe stanje korisnika iz tog session-a.

Koja je zapravo razlika između Session i Cookie?
- Različita lokacija čuvanja, Cookie se čuva na klijentu, Session se čuva na serveru.
- Različiti tipovi podataka, Cookie može čuvati samo ASCII, Session može čuvati bilo koji tip podataka, opšte u session možemo čuvati neke uobičajene informacije o promenljivim, kao UserId itd.
- Različita važnost, Cookie može biti podešen da dugo traje, kao funkcija podrazumevanog prijavljivanja koju često koristimo, Session opšte traje kraće, klijent se zatvori ili session istekne će postati nevažećim.
- Različita politika privatnosti, Cookie se čuva na klijentu, lako se može neovlašćeno dobiti, ranije su ljudi čuvali korisničko ime i lozinku u Cookie-u što je dovelo do krađe informacija, Session se čuva na serveru, bezbednost je relativno bolja od Cookie-a.
- Različita veličina čuvanja, jedan Cookie ne može čuvati više od 4K podataka, Session može čuvati mnogo više podataka od Cookie-a.
Koja je veza između Session i Cookie?
Može se koristiti Cookie da beleži identifikator Session.

- Kada korisnik prvi put šalje zahtev na server, server kreira odgovarajući Session prema informacijama koje je korisnik podneo, prilikom povratka zahteva vraća informaciju o jedinstvenom identifikatoru SessionID ovog Session-a klijentu (pretraživaču), pretraživač primi informaciju SessionID koju je vratio server, zatim sprema ovu informaciju u Cookie, istovremeno Cookie beleži kojem domenu pripada ovaj SessionID.
- Kada korisnik sledeći put pristupa serveru, zahtev će automatski proceniti da li postoji informacija Cookie pod ovim domenom, ako postoji, automatski šalje informacije Cookie serveru, server će dobaviti SessionID iz Cookie-a, zatim pronaći odgovarajuće informacije Session prema SessionID-u, ako nije pronađeno, znači da korisnik nije prijavljen ili prijava je istekla, ako je pronađen Session dokazuje da je korisnik već prijavljen može izvršiti naredne operacije.
Kako tretirati Session u distribuiranoj okolini?
U distribuiranoj okolini, zahtevi klijenta prolaze kroz balansiranje opterećenja, mogu biti dodeljeni različitim serverima, ako se dva zahteva jednog korisnika ne padnu na isti server, na novom serveru nema Session koji beleži stanje korisnika.
Šta raditi u ovom slučaju?
Može se koristiti Redis i druge distribuirane keš memorije za čuvanje Session, deljenje između više servera.

Šta ako klijent ne može koristiti Cookie?
Moguće je da klijent ne može koristiti Cookie, na primer pretraživač onemogućio Cookie, ili klijent je Android, IOS itd.
Šta raditi u ovom slučaju? Gde čuvati SessionID? Kako ga poslati serveru?
Prvo čuvanje SessionID, može se koristiti lokalna memorija klijenta, kao sessionStorage pretraživača.
Zatim kako ga poslati?
- Nalepiti u URL: direktno staviti SessionID kao parameter URL zahteva
- Staviti u zaglavlje zahteva: staviti SessionID u zaglavlje zahteva, češće se koristi.
GitHub open-sorsna baza znanja sa preko 17.000 zvezdica "Ergov put napredovanja u Javi" prvo izdanje PDF konačno je stiglo! Uključuje osnovnu Java sintaksu, nizove&stringove, OOP, kolekcione okvire, Java IO, rukovanje izuzecima, nove Java osobine, mrežno programiranje, NIO, konkurentno programiranje, JVM itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Fantastično, Java tutorijal sa preko 17.000 zvezdica na GitHubu
TCP
26.Detaljno objasnite TCP trostruko rukovanje
TCP (Transmission Control Protocol) trostruko rukovanje je proces uspostavljanja pouzdane veze između dva TCP hosta. Ovaj mehanizam osigurava da je komunikacija obe strane sinhronizovana, i pre početka prenosa podataka, obe strane su spremne za komunikaciju.

①,Prvo rukovanje: SYN (na početku su svi CLOSE, zatim server ulazi u LISTEN)
- Iniciranje veze: Klijent šalje TCP segment na server. U zaglavlju ovog segmenta, SYN bit je postavljen na 1, pokazujući da je ovo zahtev za vezu. Istovremeno, klijent nasumično bira broj sekvence (Sequence Number), pretpostavimo x, šalje ga serveru.
- Svrha: Klijent obaveštava server da želi da uspostavi vezu, i obaveštava server o sopstvenom početnom broju sekvence.
- Stanje: Klijent ulazi u SYN_SENT stanje.
②,Drugo rukovanje: SYN + ACK
- Potvrda i odgovor: Server primi zahtev za vezu klijenta, ako složi da uspostavi vezu, šalje odgovarajući TCP segment klijentu. U ovom segmentu, i SYN bit i ACK bit su postavljeni na 1. Server takođe bira sopstveni nasumični broj sekvence, pretpostavimo y, i povećava broj sekvence klijenta za 1 (tj. x+1) kao broj potvrde (Acknowledgment Number), šalje ga klijentu.
- Svrha: Server kaže klijentu da je primio zahtev za vezu, i obaveštava klijenta o sopstvenom početnom broju sekvence.
- Stanje: Server ulazi u SYN_RCVD stanje.
③,Treće rukovanje: ACK
- Konačna potvrda: Klijent primi odgovor servera, još uvek treba da pošalje potvrdu serveru. U ovom TCP segmentu, ACK bit je postavljen na 1, broj potvrde je postavljen na broj sekvence servera povećan za 1 (tj. y+1), a sopstveni broj sekvence je x+1.
- Svrha: Klijent potvrđuje da je primio sinhroni odgovor servera, completira trostruko rukovanje, uspostavlja vezu.
- Stanje: Klijent ulazi u ESTABLISHED stanje, kada server primi ovaj paket, takođe ulazi u ESTABLISHED stanje
Jednostavnim rečima, TCP trostruko rukovanje je:
Pre 30 godina na selu, telefoni nisu bili uobičajeni, zato je komunikacija ovisila o vicanju.
Lao Zhang i Lao Wang su susedi, jednog dana Lao Zhang je išao na polje, kućna se desilo nešto, pa je pažljiv sused Lao Zhang brzo trčao do sela, počeo da zove Lao Wanga.
- Lao Wang: Lao Zhane! Ja sam Lao Wang, da li me čuješ?
- Lao Zhang čuo, to je glas Lao Wang-a: Lao Wang, Lao Wang, ja sam Lao Zhang, čujem te, da li te čuješ?
- Lao Wang čuo, da, to je Lao Zhang: Lao Zhane, čujem te, imam ti nešto da kažem.
"Tvoja žena rađa, hitno se vrati!"
Lao Zhang se žurno vratio kući, žena je uspešno rodila zdravog dečaka. Priča rukovanja je puna sreće i lepote.

Možete li dati drugi primer TCP trostrukog rukovanja?
Naravno, ti (klijent) si na gužvnoj žurki sreo lepu devojku (server) kojom želiš da razgovoriš. Zato što je okolina bučna, treba da potvrdite da su obe strane spremne za komunikaciju, i jasno čujete svaku reč koju druga strana kaže.
①,Prvo rukovanje: Pozdrav
- Ti prilaziš lepoj devojci, glasno kažeš: "Hej, ja sam Xiao Er, da li možemo da ćaskamo?" (Ti si poslao zahtev za vezu, rekao si serveru da želiš duboku razmenu, i dao si mu svoj WeChat ID
x, to jest tačka vašeg razgovora)
②,Drugo rukovanje: Odgovor druge strane
- Lepa devojka vidi da si zgodan i imaš stil, odgovara: "Zdravo, ja sam Xiao Qing, možemo da ćaskamo." (Server prihvata tvoj zahtev, takođe voli duboku razmenu, kaže ti svoj WeChat ID
y, i potvrđuje tvoj WeChat IDx+1, pokazuje da je spreman)
③,Treće rukovanje: Potvrda spremnosti
- Ti čuješ odgovor lepe devojke, kažeš joj: "Fantastično, razgovarajmo na WeChat-u." (Ti potvrđuješ odgovor lepe devojke, takođe kažeš da si spreman, putem slanja potvrde
y+1)
④,Početak razgovora
U ovom trenutku, vi dvoje ste potvrdili da ste spremni za duboku razmenu, možete početi razgovor.
Kažite nešto o konceptu SYN?
SYN je bit u TCP protokolu koji se koristi za uspostavljanje veze, puno ime je Synchronize Sequence Numbers, to jest sinhronizacija brojeva sekvence.

SYN ne samo osigurava sinhronizaciju brojeva sekvence, čini da se naredni podaci mogu uređeno preneti, već sprečava da stari segmenti budu pogrešno smatrani kao nova veza.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 9 kompanije ByteDance za Feishu backend: Zašto TCP treba trostruko rukovanje
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 5 kompanije TP United za Java backend: TCP trostruko rukovanje, koncept SYN
27.🌟Zašto je TCP trostruko rukovanje trostruko, zašto ne može biti dvostruko? Zašto ne može biti četvorostruko?
Korišćenje trostrukog rukovanja može uspostaviti pouzdanu vezu. Svrha ovog procesa je osigurati da obe strane znaju da je druga strana spremna za komunikaciju, i sinhronizovati brojeve sekvence obe strane, čuvajući redosled i integritet paketa podataka.
Zašto TCP trostruko rukovanje ne može biti dvostruko?
---tok intervjua može biti izostavljen, ali treba razumeti start---
- Da bi se sprečilo server da čeka dugo, dok ne prođe sva lepa vremena.
- Da bi se sprečilo da iznenada nenadbudni zahtev za vezu klijenta stigne na server.
Treba znati, mrežni prenos ima kašnjenje (prolazi kroz mrežna optička vlakna, WIFI, satelitske signale itd.).
Ako klijent pokrene SYN=1 prvo rukovanje. Server je pravovremeno odgovorio sa SYN=2 i ACK=1 drugo rukovanje, ali ovaj ACK=1 potvrdni segment je izgubljen usled nekog razloga u procesu prenosa.
Ako nema trećeg rukovanja da kaže serveru da je klijent primio odgovor servera, server ne zna da li je klijent primio.
Zato server neprestano čekajući otvara port i čeka da klijent pošalje poruku, ali u stvari klijent nije primio odgovor servera, razočaran pobegao.

Ovo je kao što si tražio kontakt lepe devojke, ona ti je odgovorila, ali ti nislu čuo, mislio si da se ne sviđaš, ljut pobegao, preostala lepa devojka i dalje te čeka...
Postoji još jedna situacija, stari, kašnjeni zahtev za vezu (SYN=1) je prihvaćen od strane servera, uzrokujući da server pogrešno otvara vezu koja više nije potrebna.

Na primer: pretpostavimo da ti (klijent) šalješ e-poruku (zahtev za vezu) prijatelju (serveru. Zato što je ova e-poruka kasnila, prijatelj nije dobio. Zato odlučuješ da pošalješ novu e-poruku. Prijatelj primio drugu e-poruku, uspešno ste uspostavili vezu i počeli komunikaciju.
Ali, posle dugo vremena, ona stara e-poruka iznenada stigne kod prijatelja. Ako nema mehanizma da prepozna i obradi ove kašnjene e-poruke, prijatelj može misliti da je to novi zahtev za vezu, i pokuša da odgovori, ali ti si već poslao novi zahtev, stari više ne treba. Ovo dovodi do nepotrebne zabune i gubitka resursa.
---tok intervjua može biti izostavljen, ali treba razumeti end---
- Prvo rukovanje: klijent šalje SYN paket (zahtev za vezu) serveru, ako ovaj paket kasni, klijent neće čekati večito, može ponoviti i poslati novi zahtev za vezu.
- Drugo rukovanje: server primi SYN paket, šalje SYN-ACK paket (potvrdu primanja zahteva za vezu) klijentu.
- Treće rukovanje: klijent primi SYN-ACK paket, zatim šalje ACK paket serveru, potvrđuje primanje odgovora servera.
Zašto ne četvorostruko?
Trostruko rukovanje je dovoljno za uspostavljanje pouzdane veze, nije potrebno dodatno rukovanje.
Šta je to napad poplave?
Napad poplave (SYN Flood Attack) je čest DoS (Denial of Service) napad, napadač će poslati veliki broj lažnih TCP zahteva za vezu, uzrokujući da resursi servera istroše, ne mogu da obrade normalne zahteve za vezu.
Odbijanje polu-povezivanja, takođe poznato kao SYN napad poplave ili SYN Flood.
Takozvana polu-povezivanje se odnosi na procesu TCP trostrukog rukovanja, kada server primi prvi SYN paket od klijenta, odgovara sa SYN-ACK paketom, u ovom trenutku veza je u "polu-otvorenom" stanju, jer uspostavljanje veze još uvek treba da klijent pošalje poslednji ACK paket.
Pre nego što primi poslednji ACK paket, server će dodeliti određene resurse ovjoj nedovršenoj vezi, i zadržati mesto ove veze u svojoj redi.
Ako treba da ponovo dizajnirate, kako biste to dizajnirali?
Ako ponovo dizajnirate proces uspostavljanja TCP veze, možete razmisliti o uvodu SYN cookies, ova tehnika kroz kodiranje informacija o vezi u SYN-ACK odgovoru, tako da može verifikovati klijenta bez zauzimanja velikih resursa.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 9 kompanije ByteDance za Feishu backend: Zašto TCP treba trostruko rukovanje
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog intervjua kandidata 2 kompanije Meituan za logistiku optimizaciju 2: Zašto trostruko rukovanje, koje su mane, napad poplave, odbijanje polu-povezivanja, ako treba ponovo dizajnirati, kako biste dizajnirali
28.Šta se dešava ako svaki put ne primi poruku u trostrukom rukovanju?
- Prvo rukovanje server nije primio SYN segment
Server neće preduzeti nikakve radnje, a klijent zato što u određeno vreme nije primio potvrdni segment servera, posle određenog vremena ponovo će poslati SYN segment, ako i dalje nema odgovora, ponoviće ovaj proces, dok broj ponavljanja ne premaši maksimalno ograničenje broja ponavljanja, vratitiće neuspeh uspostavljanja veze.
- Drugo rukovanje klijent nije primio ACK segment odgovora servera
Klijent će nastaviti da ponavlja, dok ne premaši ograničenje broja, a server će u ovom trenutku blokirati na accept(), čekajući da klijent pošalje ACK segment
- Treće rukovanje server nije primio ACK segment koji je klijent poslao
Server će takođe usvojiti sličan mehanizam timeout-a ponavljanja klijenta, ako broj ponavljanja premaši ograničenje, poziv accept() vraća -1, server neuspešno uspostavlja vezu, a u ovom trenutku klijent smatra da je uspešno uspostavio vezu, zato počinje da šalje podatke serveru, ali poziv accept() sistema servera se već vratio, u ovom trenutku nije u stanju praćenja, zato server prima podatke koje je klijent poslao poslaće RST segment klijentu, uklanja stanje jednostrane uspostavljanja veze klijenta.
29.Zašto se drugo rukovanje vraća ACK, još uvek treba vratiti SYN?
ACK služi da kaže klijentu da su primljeni podaci bez greške.
A vraćanje SYN služi da kaže klijentu da odgovor servera zaista odgovara segmentu koji je klijent poslao.
30.Može li treće rukovanje poneti podatke?
Treće rukovanje može poneti podatke.
U ovom trenutku klijent je već u ESTABLISHED stanju. Za klijenta, veza je uspešno uspostavljena, i potvrđuje da su prijem i slanje mogućnosti servera normalne.
Prvo rukovanje ne može poneti podatke iz razloga bezbednosti, jer ako se dozvoli nošenje podataka, napadač može svaki put u SYN segmentu nositi velike količine podataka, doćiće do toga da server troši više vremena i prostora za obradu ovih segmenata, uzrokuje potrošnju CPU-a i memorije.
31.Znate li TCP polu-povezano stanje?
TCP polu-povezanost se odnosi na proces TCP trostrukog rukovanja, server je primio SYN paket klijenta, ali još uvek nije completirao treće rukovanje, veza je u nedovršeno uspostavljenom stanju.

Ako server odgovori sa SYN-ACK, ali klijent još uvek nije odgovorio sa ACK, ova veza će uvek ostati u redu polu-povezanosti, dok ne istekne ili bude odbijena.
Kažite nešto o redu polu-povezanosti?
Pre nego što TCP uđe u trostruko rukovanje, server će iz CLOSED stanja preći u LISTEN stanje, istovremeno kreira dva reda unutar: red polu-povezanosti (SYN red) i red potpune povezanosti (ACCEPT red).

Ime govori, red polu-povezanosti čuva nedovršene veze trostrukog rukovanja, red potpune povezanosti čuva completirane veze trostrukog rukovanja.
- Pri TCP trostrukom rukovanju, klijent šalje SYN na server, server primi, zatim odgovara sa ACK i SYN, stanje se menja iz LISTEN u SYN_RCVD, u ovom trenutku ova veza se gura u SYN red, to jest red polu-povezanosti.
- Kada klijent odgovori sa ACK, server primi, trostruko rukovanje je completirano. U ovom trenutku veza čeka da bude preuzeta od strane konkretne aplikacije, pre nego što bude preuzeta, gura se u ACCEPT red, to jest red potpune povezanosti.
Šta je SYN Flood?
SYN Flood je tipičan DDos napad, u kratkom vremenu falsifikuje nepostojeće IP adrese, šalje veliki broj SYN segmenata na server. Kada server odgovori sa SYN+ACK segmentom, neće dobiti ACK odgovor, tada veze u SYN redu neće napustiti red, dugoro će napuniti SYN prijemni red (red polu-povezanosti) servera, čineći da server ne može da služi normalnim korisnicima.

Koja su rešenja?
Postoje uglavnom syn cookie i SYN Proxy firewall itd.
- syn cookie: Nakon primanja SYN paketa, server prema određenom metodu, koristeći izvornu adresu paketa, port i druge informacije kao parametre računa vrednost cookie kao sopstveni broj sekvence SYNACK paketa, posle odgovaranja sa SYN+ACK, server ne odmah dodeljuje resurse za obradu, čeka da pošiljalac pošalje ACK paket, zatim ponovo računa da li je broj sekvence potvrde u paketu ispravan prema izvornoj adresi paketa, portu, ako je ispravan uspostavlja vezu, inače odbacuje taj paket.
- SYN Proxy firewall: Firewall servera će zameničiti i odgovoriti na svaki primljeni SYN segment, i održavati polu-povezanost. Kada pošiljalac vrati ACK paket, ponovo konstruiše SYN paket i šalje na server, uspostavlja pravu TCP vezu.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 30 kompanije Tencent Music: Koje je stanje tcp polu-povezanosti?
32.🌟Kažite proces TCP četvorostrukog rukovanja?
Proces prekida TCP veze je slikovito sumiran kao četvorostruko rukovanje.

Prvo rukovanje: Klijent šalje FIN krajnji segment serveru, pokazujući da klijent nema više podataka za slanje, ali i dalje može primiti podatke. Klijent ulazi u FIN-WAIT-1 stanje.
Drugo rukovanje: Server primi FIN segment, šalje ACK segment klijentu, potvrđuje primanje FIN zahteva klijenta. Server ulazi u CLOSE-WAIT stanje, klijent ulazi u FIN-WAIT-2 stanje.
Treće rukovanje: Server šalje FIN segment klijentu, pokazujući da server nema više podataka za slanje. Server ulazi u LAST-ACK stanje.
Četvrto rukovanje: Klijent primi FIN segment, šalje ACK segment serveru, potvrđuje primanje FIN zahteva servera. Klijent ulazi u TIME-WAIT stanje, čeka određeno vreme da osigura da je server primio ACK segment. Server primi ACK segment ulazi u CLOSED stanje. Klijent nakon čekanja određenog vremena takođe ulazi u CLOSED stanje.
Jednostavnim rečima četvorostruko rukovanje:
Ako "single dog" blogger ima devojku — zato što blogger radi 996, posle posla na blog, nema vremena za devojku, devojka ne može da trpi.
- Devojka: Psi muškaro, nedavno me ne poznaješ, da li me još voliš? Da li imaš psa izvan kuće? Želim da se rastavim od tebe?
- "Sandiao" blogger se zanema, besnost napuhla: Rastavimo se, rastavimo se, ne ću da te zabavljam, sačekaj da sredim stvari.
"Sandiko" blogger pažljivo pakira svoju mehaničku tastaturu sa plavim osovinama.
Hmm, glupa ženo, ja sam sredio, ja prvo odlazim, vidimo se!
Devojka: Odlazi, odlazi što dalje mogu, što dalje bolje, neću te više videti u životu.
Priča rukovanja je uvek puna tuge i žalosti!

- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua stažisti kandidata 25 kompanije Tencent za backend razvoj: TCP i UDP, proces uspostavljanja i prekidanja TCP veze
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 19 kompanije ByteDance za Tomato Novel: Proces prekidanja TCP veze
33.🌟Zašto TCP rukovanje treba biti četvorostruko?
Zato što je TCP protokol punog duplexa komunikacije, slanje i primanje podataka zahteva dva puta tamo i ovamo, to jest četiri puta, da obe strane mogu ispravno zatvoriti vezu.

- Prvo rukovanje: klijent označava da je slanje podataka completirano, spreman za zatvaranje, potvrdite.
- Drugo rukovanje: server odgovara da je ok, odmah ću completirati obradu podataka, sačekajte.
- Treće rukovanje: server označava da je obrada completirana, može se zatvoriti.
- Četvrto rukovanje: klijent kaže da je ok, ulazi u TIME_WAIT stanje, osigurava da server zatvara vezu, zatim zatvara svoju vezu.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 30 kompanije Tencent Music: Zašto je tcp rukovanje četvorostruko, a ne trostruko?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 34 kompanije ByteDance: Zašto je tcp rukovanje trostruko, a rukovanje četvorostruko
memo: 4. septembra 2025. promenjeno do ovde, danas član planete postavio pitanje u planeti kaže da je dobio ponudu od iFlytek-a i CXM, CXM je direktno ponudio platu, zaista brzo.

34.U procesu TCP četvorostrukog rukovanja, zašto treba čekati 2MSL pre ulaska u CLOSED stanje zatvaranja?
Zašto treba čekati?
1. Da bi se osiguralo da poslednji ACK segment koji klijent šalje može stići do servera. Ovaj ACK segment može biti izgubljen, zbog čega će server u LAST-ACK stanju ne dobiti potvrdu poslatog FIN + ACK segmenta. Server će ponovo poslati ovaj FIN+ACK segment timeout-om, a klijent može primiti ovaj ponovljeni FIN+ACK segment u roku od 2MSL (timeout + 1MSL transfer). Zatim klijent ponovo šalje potvrdu, ponovo pokreće 2MSL tajmer. Konačno, klijent i server normalno ulaze u CLOSED stanje.
2. Sprečavanje da se zastareli zahtevni segmenti pojave u ovoj vezi. Klijent nakon slanja poslednjeg ACK segmenta, nakon još 2MSL vremena, može učiniti da se svi segmenti generisani u trajanju ove veze nestanu iz mreže. Time se može sprečiti da se zastareli zahtevni segmenti pojave u sledećoj vezi.
Zašto je vreme čekanja 2MSL?
MSL je Maximum Segment Lifetime, maksimalno vreme postojanja segmenta, to je najduže vreme da segment postoji na mreži, nakon ovog vremena segment će biti odbačen.
TIME_WAIT čeka 2 puta MSL, razumno objašnjenje je: u mreži mogu postojati paketi od pošiljaoca, kada te pakete primaoc obrati i pošalje odgovor, zato jedan tamo i jedan ovamo treba čekati 2 puta.

Na primer, ako pasivna strana zatvaranja nije primila poslednji ACK segment prekida veze, pokrenuće timeout ponovo slati Fin segment, druga strana primi FIN, ponovo će poslati ACK pasivnoj strani zatvaranja, jedan tamo i jedan ovamo baž 2 MSL.
35.Koja je svrha timer-a održavanja?
Pored timer-a vremena čekanja, TCP ima još jedan timer održavanja (keepalive timer).
Zamislite ovakav scenario: klijent je aktivno uspostavio TCP vezu sa serverom. Ali kasnije host klijenta iznenada doživi kvar. Očigledno, server nakon toga neće moći da prima podatke od klijenta. Zato treba preduzeti mere da server više ne čeka uzalud. Ovo zahteva korišćenje timer-a održavanja.
Server svaki put kada primi podatke klijenta, ponovo postavlja timer održavanja, vreme postavljanja je obično dva sata. Ako dva sata ne primi podatke klijenta, server će poslati jedan detektivni segment, zatim svakih 75 sekundi pošalje jedan. Ako kontinuirano pošalje 10 detektivnih segmenata i dalje nema odgovora klijenta, server smatra da je klijent doživeo kvar, zatim zatvara ovu vezu.
36.Koja su stanja i značenja CLOSE-WAIT i TIME-WAIT?
Koja je značenje CLOSE-WAIT stanja?
Server primi zahtev za zatvaranje veze klijenta i potvrdi, zatim ulazi u CLOSE-WAIT stanje. U ovom trenutku server možda još uvek ima neke podatke koje nisu completirane transmisije, zato ne može odmah zatvoriti vezu, a CLOSE-WAIT stanje služi da osigura da server completira obradu preostalih podataka pre zatvaranja veze.
Koja je značenje TIME-WAIT?
TIME-WAIT se dešava u četvrtom rukovanju, kada klijent pošalje ACK potvrdu FIN segmenta druge strane, ulazi u TIME_WAIT stanje.

Postoje dve glavne svrhe:
- U TIME_WAIT stanju, klijent može ponovo poslati ACK da osigura da druga strana normalno zatvara vezu.
- Nakon 2MSL vremena trajanja TIME_WAIT, osigurava da se stari paketi potpuno nestanu, izbegavajući da ometaju uspostavljanje nove veze.
Dopuna: MSL (Maximum Segment Lifetime): Maksimalno vreme postojanja TCP segmenta u mreži, obično 30 sekundi do 2 minuta
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 19 kompanije ByteDance za Tomato Novel: TIME_WAIT
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 29 kompanije Tencent za Java backend: Kažite TCP TIME_WAIT
37.Šta problem previše TIME_WAIT stanja uzrokuje? Kako rešiti?
Šta problem previše TIME_WAIT stanja uzrokuje?
Ako server ima TCP u TIME_WAIT stanju, to znači da je strana servera pokrenula zahtev za prekid.
Glavne štete previše TIME_WAIT stanja su dve:
Prva je trošenje memorijskih resursa,
Druga je trošenje resursa porta, jedna TCP veza troši barem jedan lokalni port,
Kako rešiti previše TIME_WAIT stanje?
- Server može postaviti SO_REUSEADDR soket da obavesti kernel, ako je port zauzet, ali TCP veza može ponovo koristiti port kada je u TIME_WAIT stanju.
- Takođe može koristiti dugu vezu da smanji uspostavljanje i prekid TCP veze, u poslovima duge veze često nije potrebno razmatrati TIME_WAIT stanje.
38.Kažite format zaglavlja TCP segmenta?
Jedan TCP segment uglavnom se sastoji od zaglavlja (Header) i podataka, zaglavlje uključuje razne kontrolne informacije potrebne za pouzdan prenos podataka, kao što su broj sekvence, broj potvrde, veličina prozora itd.

- Izvorni port (Source Port): 16 bita (2 bajta), koristi se za identifikaciju aplikacije pošiljaoca.
- Ciljni port (Destination Port): Takođe 16 bita, koristi se za identifikaciju aplikacije primaoca.
- Broj sekvence (Sequence Number): 32 bita, koristi se za identifikaciju redosleda prvog bajta podataka tokova podataka koji TCP šalje, osigurava uređeno primanje podataka.
- Broj potvrde (Acknowledgment Number): 32 bita, ako je ACK flag postavljen, ovo polje uključuje broj sekvence potvrde slanja, to jest sledeći broj sekvence koji TCP primaoc očekuje da primi.
- Offset podataka (Data Offset): 4 bita, označava dužinu zaglavlja TCP segmenta, koristi se za indiciranje gde počinju podaci.
- Rezervisano (Reserved): 6 bita, rezervisano za buduću upotrebu, trenutno mora biti postavljeno na 0.
- Kontrolni bitovi (Flags): Ukupno 6 bita, uključuje URG (da li je polje hitnog pokazivača važeće), ACK (da li je polje potvrde važeće), PSH (podstiče primaoca da što pre obradi ovaj segment sloju aplikacije), RST (resetovanje veze), SYN (sinhronizacija broja sekvence, koristi se za uspostavljanje veze), FIN (kraj slanja podataka).
- Veličina prozora (Window): 16 bita, koristi se za kontrolu toka, označava koliko bajtova podataka primaoc još uvek može primiti (na osnovu veličine prijemnog bafera).
- Provera sume (Checksum): 16 bita, pokriva proveru sumu celog TCP segmenta (uključujući TCP zaglavlje, podatke i pseudo-zaglavlje), koristi se za detektovanje bilo kakvih promena podataka u procesu prenosa.
- Hitni pokazivač (Urgent Pointer): 16 bita, važi samo kada je URB kontrolni bit postavljen, pokazuje poziciju hitnih podataka u segmentu.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 9 kompanije ByteDance za Feishu backend: Struktura TCP segmenta
39.Zašto je TCP pouzdan?
TCP prvo obezbeđuje pouzdanost veze putem trostrukog i četvorostrukog rukovanja, zatim putem provere sume, broja sekvence, potvrde, timeout-a ponavljanja, kliznog prozora itd. mehanizama osigurava pouzdan prenos podataka.
Preporučeno čitanje: Metoda izračuna TCP provere sume
①,Provera sume: TCP segment uključuje polje provere sume, koristi se za detektovanje promena segmenta u procesu prenosa. Ako primaoc detektuje grešku provere sume, odbaciće ovaj segment.

②,Mehanizam broja sekvence/potvrde: TCP deli podatke na više malih segmenata, svaki segment podataka ima jedinstven broj sekvence, osigurava uređen i completan transmisiju paketa podataka. Istovremeno, ako pošiljalac ne primi potvrdu primaoca, ponovo će poslati podatke.

③,Kontrola toka: Primaoc će reći pošiljaocu svoju prijemnu mogućnost slanjem veličine prozora. Pošiljalac će prilagoditi brzinu slanja prema veličini prozora, izbegavajući mrežno zagušenje.

④,Timeout ponavljanje: Ako pošiljalac poslati paket podataka premašuje maksimalno vreme postojanja, primaoc još uvek nije primio, pošiljalac će ponovo poslati paket podataka da osigura da se izgubljeni podaci ponovo prenesu.

⑤,Kontrola zagušenja: TCP će usvojiti strategiju sporog pokretanja, na početku šalje malo, zatim postepeno povećava, kada detektuje mrežno zagušenje, smanjiće brzinu slanja. Kada se mrežno zagušenje smiri, brzina transmisije će automatski oporaviti.

- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kandidata 13 kompanije Shopee: Zašto je tcp pouzdan
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 30 kompanije Tencent Music: Kako TCP osigurava ovaj bezbedan prenos?
40.Kažite TCP kontrolu toka?
TCP pruža mehanizam kojim pošiljalac može kontrolisati količinu podataka koja se šalje prema stvarnoj prijemnoj sposobnosti primaoca, to je kontrola toka.
TCP koristi klizni prozor za kontrolu toka, pogledajmo kratki proces:
- Prvo obe strane izvrše trostruko rukovanje, inicijalizuju svoje veličine prozora, obe su 400 bajtova.

- Ako trenutni pošiljalac šalje 200 bajtova primaocu, tada se
SND.NXTpošiljaoca pomera za 200 bajtova desno, to jest trenutno dostupan prozor se smanjuje za 200 bajtova. - Primaoc primi, stavi u red čekanja, REV.WND =400-200=200 bajtova, zato win=200 bajtova vraća pošiljaocu. Primaoc će u zaglavlju ACK segmenta poneti smanjeni klizni prozor 200 bajtova
- Pošiljalac opšt šalje 200 bajtova, 200 bajtova stigne, nastavi da stavlja u red čekanja. Ali u ovom trenutku, zato što je veliko opterećenje, primaoc ne može obraditi toliko bajtova, može obraditi samo 100 bajtova, preostalih 100 bajtova nastavi da stavlja u red čekanja. U ovom trenutku, REV.WND = 400-200-100=100 bajtova, to jest win=100 vraća pošiljaocu.
- Pošiljalac nastavi da šalje 100 bajtova, u ovom trenutku, prijemni prozor win postaje 0.
- Pošiljalac prestaje da šalje, pokreće periodični zadatak, svakog određenog vremena pita primaoca, dok win ne postane veće od 0, tada nastavlja da šalje.
41.Detaljno kažite TCP klizni prozor?
TCP šalje jedan podatak, ako mora dobiti potvrdu da bi poslao sledeći podatak. Ovo ima nedostatak: efikasnost će biti prilično niska.
"Metaforom, kada ćaskamo na WeChat-u, ti napišeš jednu rečenicu, ja odgovorim jednom, zatim ti možeš napisati sledeću. Ako ja ne odgovorim na vreme? Ti ćeš zadržati rečenicu i ne govoriti? Zatim glupo čekaš moj odgovor, zatim nastavljaš da šalješ sledeću rečenicu?"
Da bi rešio ovaj problem, TCP uvodi prozor, to je prostor keš memorije koji otvara operativni sistem. Vrednost veličine prozora označava maksimalnu vrednost koja se može nastaviti slati bez čekanja potvrde.
TCP zaglavlje ima polje koje se zove win, to jest taj 16-bitni prozor, kaže drugoj strani koliko bajtova podataka može još sadržati TCP prijemni bafer, druga strana može kontrolisati brzinu slanja podataka, time dostižući kontrolu toka.
"Jednostavnije rečeno, svaki put kada primaoc primi paket podataka, prilikom slanja potvrdne poruke, istovremeno kaže pošiljaocu koliko slobodnog prostora ima u sopstvenom baferu, slobodan prostor bafera zovemo prozor prijema. To je win."
TCP klizni prozor je podeljen na dve vrste: prozor slanja i prozor prijema. Prozor slanja uključuje četiri glavna dela, kao što sledi:
- Već poslato i već primljeno ACK potvrdu
- Već poslato ali nije primljeno ACK potvrdu
- Neslato ali može se poslati
- Neslato i ne može se poslati

- U tamnoplavoj kućici je prozor slanja.
- SND.WND: označava veličinu prozora slanja, na gornjoj slici broj kućica u isprekidanoj liniji je 10, to jest veličina prozora slanja je 10.
- SND.NXT: sledeća pozicija slanja, pokazuje na broj sekvence prvog bajta koji može biti poslat ali nije poslat.
- SND.UNA: apsolutni pokazivač, pokazuje na broj sekvence prvog bajta koji je poslat ali nije potvrđen.
Prozor prijmana uključuje tri glavna dela, kao što sledi:
- Već uspešno primljeno i potvrđeno
- Nije primljeno podatak ali može primiti
- Nije primljeno podatak i ne može primiti podatak

- U plavoj kućici je prozor prijmana.
- REV.WND: označava veličinu prozora prijmana, na gornjoj slici broj kućica u isprekidanoj liniji je 9.
- REV.NXT: sledeća pozicija prijema, pokazuje na broj sekvence prvog bajta koji nije primljen ali može biti primljen.
42.Znate li Nagle algoritam i kašnjeću potvrdu?
Što rade Nagle algoritam i kašnjeća potvrda?
Kada su podaci koje TCP segment nosi vrlo mali, na primer nekoliko bajtova, tada je efikasnost cele mreže vrlo niska, jer svaki TCP segment ima 20 bajtova TCP zaglavlja, takođe ima 20 bajtova IP zaglavlja, a podataka su samo nekoliko bajtova, zato u celom segmentu proportion efektivnih podataka postaje vrlo nizak.

Ovo je kao što kurir vozim veliki kamion da dostavi mali paket, tako neefikasno.
Zato se pojavljuju dva uobičajena strategije, da bi se smanjilo slanje malih segmenata, to su:
- Nagle algoritam
- Kašnjeća potvrda
Nagle algoritam
Nagle algoritam: Bilo koji trenutak, najviše jedan ne-potvrđeni mali segment postoji. Takozvani "mali segment" se odnosi na blok podataka manji od MSS veličine, "ne-potvrđen" znači da jedan blok podataka poslat, a nije primljeno potvrdu da je druga strana primila da je primila ovaj podatak.
Strategija Nagle algoritma:
- Ako nema već poslatog ne-potvrđenog segmenta, odmah šalji podatke.
- Ako postoji ne-potvrđeni segment, sve dok "nema već poslatog ne-potvrđenog segmenta" ili "dužina podataka dostigne MSS veličinu", zatim šalji podatke.
Sve dok nije zadovoljeno jedan od gore navedenih uslova, pošiljalac stalno kupi podatke, dok ne zadovolji gore navedene uslove slanja.
Kašnjeća potvrda
U stvari, kada ACK ne nosi podatke, njena mrežna efikasnost je takođe vrlo niska, jer ima 40 bajtova IP zaglavlja i TCP zaglavlja, ali nema nosive podatke segment.
Da bi rešio problem niske efikasnosti ACK transmisije, stoga je izvedeno TCP kašnjeća potvrda.
Strategija TCP kašnjeće potvrde:
- Kada postoje odgovarajući podaci za slanje, ACK će odmah biti poslat zajedno sa odgovarajućim podacima drugoj strani
- Kada nema odgovarajućih podataka za slanje, ACK će biti kašnjen određeno vreme, čekajući da li postoje odgovarajući podaci koji mogu biti poslati zajedno
- Ako u procesu čekanja kašnjenja slanja ACK, drugi segment podataka druge strane stigne, u ovom trenutku će odmah poslati ACK
Opšte uzevši, Nagle algoritam i kašnjeća potvrda ne mogu se koristiti zajedno, Nagle algoritam znači kašnjenje slanja, kašnjeća potvrda znači kašnjenje prijema, dva zajedno će prouzrokovati veće kašnjenje, proizvestiće probleme performansi.
43.Kažite TCP kontrolu zagušenja?
Šta je kontrola zagušenja?
Kontrola toka služi da izbegne da podaci pošiljaoca popune keš primaoca, ali ne može kontrolisati celu mrežu.
Opšte uzevši, računarske mreže su u deljenom okruženju. Zato je moguće da komunikacija između drugih hostova uzrokuje mrežno zagušenje.
Kada se mreža zaguši, ako nastavimo da šaljemo velike količine paketa, može doći do kašnjenja, gubitka paketa itd., tada TCP će ponovo poslati podatke, ali ponovno slanje povećava opterećenje mreže, zatim dovodi do većeg kašnjenja i više gubitka, ulazi u začarani krug...
Zato, TCP je dizajniran kao veoma nekičiji protokol, kada se mreža zaguši, TCP će se žrtvovati, smanjiti tok podataka.
Svrha kontrole zagušenja je izbeći da podaci pošiljaoca popunu celu mrežu.
Kao cevni vodovod, ne možete dozvoliti previše vode (tok podataka) da uđe u cev, ako pređe nosivost cevi, cev će se prsnuti (gubitak paketa).

Pošiljalac će održavati promenljivu zagušeni prozor cwnd, reguliše količinu podataka za slanje.
Šta je zagušeni prozor? Koja je veza sa prozorom slanja?
Zagušeni prozor cwnd je promenljiva stanja koju održava pošiljalac, menja se dinamički prema stepenu zagušenja mreže.
Prozor slanja swnd i prozor prijmana rwnd su u relaciji približno jednaki, nakon dodavanja koncepta zagušenog prozora, u ovom trenutku vrednost prozora slanja je swnd = min(cwnd, rwnd), to jest manja vrednost od zagušenog prozora i prozora prijama.
Pravila promene zagušenog prozora cwnd:
- Dok u mreži nema zagušenja, cwnd će povećati,
- Ali kada se u mreži pojavi zagušenje, cwnd će smanjiti,
Koji algoritmi se često koriste za kontrolu zagušenja?
Kontrola zagušenja uglavnom ima nekoliko uobičajenih algoritama:

- Sporo pokretanje
- Izbegavanje zagušenja
- Desavanje zagušenja
- Brzo oporavak
①,Algoritam sporog pokretanja
Sporo pokretanje, polako pokreni.
Oznaka da nakon uspostavljanja TCP veze, na početku ne šaljemo mnogo podataka, već prvo detektujemo stepen zagušenja mreže. Od malog do velikog postepeno povećavamo veličinu zagušenog prozora, ako nema gubitka paketa, svaki put kada primi ACK, zagušeni prozor cwnd će povećati za 1 (jedinica je MSS). Svaki krug prozor slanja se povećava za dva puta, raste eksponencijalno, ako se desi gubitak paketa, zagušeni prozor se prepolovi, ulazi fazu izbegavanja zagušenja.
Na primer:
- Nakon uspostavljanja veze, na početku inicijalizujemo cwnd = 1, označava da može poslati 1 MSS veličine podataka.
- Kada primi jednu ACK potvrdu, cwnd se povećava za 1, tada jednom može poslati 2
- Kada primi 2 ACK potvrde, cwnd se povećava za 2, tada može poslati 2 više nego pre, zato ovaj put može poslati 4
- Kada ova 4 ACK potvrde stignu, svaka potvrda cwnd povećava za 1, 4 potvrde cwnd povećava za 4, tada može poslati 4 više nego pre, zato ovaj put može poslati 8.

Broj slanih paketa raste eksponencijalno.

Da bi se sprečilo da cwnd raste preveliko i uzrokuje mrežno zagušenje, treba postaviti prag sporog pokretanja ssthresh (slow start threshold) promenljivu stanja. Kada cwnd dođe do ovog praga, kao da je slavina cevi smanjena, smanjuje stepen zagušenja. To jest kada cwnd >ssthresh, ulazi u algoritam izbegavanja zagušenja.
②,Algoritam izbegavanja zagušenja
Opšte uzevši, prag sporog pokretanja ssthresh je 65535 bajtova, kada cwnd dođe do praga sporog pokretanja
- Svaki put kada primi ACK, cwnd = cwnd + 1/cwnd
- Kada prođe jedan RTT, cwnd = cwnd + 1
Očigledno ovo je algoritam linearnog rasta, izbegava prebrzo izazivanje mrežnog zagušenja.
Nastavimo sa primerom sporog pokretanja, pretpostavimo ssthresh je 8:
- Kada stigne 8 ACK potvrde, svaka potvrda povećava za 1/8, 8 ACK potvrde cwnd ukupno povećava za 1, tada ovaj put može poslati 9 MSS veličine podataka, postaje linearni rast.

③,Desavanje zagušenja
Kada se desi mrežno zagušenje gubitak paketa, postoje dve situacije:
- RTO timeout ponavljanje
- Brzo ponavljanje
Ako se desi RTO timeout ponavljanje, koristiće algoritam desavanja zagušenja
- Prag sporog pokretanja sshthresh = cwnd /2
- cwnd se resetuje na 1
- Ulazi u novi proces sporog pokretanja

Ovaj način je kao naglo kočenje pri vožnji brzine, još uvek brzo unazad, ovo...
U stvari postoji bolji način obrade, to je brzo ponavljanje. Kada pošiljalac primi 3 uzastopna dupla ACK, brzo će ponoviti, ne čeka RTO timeout da ponovi.
Algoritam desavanja zagušenja pri brzom ponavljanju:
- Veličina zagušenog prozora cwnd = cwnd/2
- Prag sporog pokretanja ssthresh = cwnd
- Ulazi u algoritam brzog oporavka
④,Brzo oporavak
Algoritam brzog ponavljanja i brzog oporavka se obično koriste zajedno. Algoritam brzog oporavka smatra, još uvek postoje 3 dupla ACK primljena, pokazuje da mreža nije toliko loša, zato nije potrebno tako jako kao RTO timeout.
Kao što je ranije rečeno, pre ulaska u brzi oporavak, cwnd i sshthresh su već ažurirani:
- cwnd = cwnd /2
- sshthresh = cwnd
Zatim, ulazi se u algoritam brzog oporavka kao što sledi:
- cwnd = sshthresh + 3
- Ponovo šalje one nekoliko dupla ACK (to jest onih nekoliko izgubljenih paketa)
- Ako opet primi dupli ACK, tada cwnd = cwnd +1
- Ako primi ACK novih podataka, cwnd = sshthresh. Zato što primanje ACK novih podataka pokazuje da je proces oporavka završen, može opet ući u algoritam izbegavanja zagušenja.

- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 5 kompanije JD za Java backend: tcp kontrola zagušenja
44.Kažite TCP mehanizam ponavljanja?
Mehanizam timeout ponavljanja je jedno od srži TCP-a, može osigurati da ako se određeni paketi izgube ili ne stignu na vreme u procesu mrežnog prenosa, TCP može ponovo poslati te pakete, da bi osigurao integritet podataka.
Njegov princip je nakon slanja određenog podatka pokrenuti tajmer, ako u određenom vremenu ne dobije ACK segmant poslatih podataka, ponovo će poslati podatke, sve dok slanje ne uspe.
Ponavljanje uključuje timeout ponavljanje, brzo ponavljanje, ponavljanje sa selektivnom potvrdom (SACK) i duplo SACK.

Koliko treba postaviti timeout vreme?
Vreme timeout ponavljanja (RTO, Retransmission Timeout) u TCP-u nije fiksna vrednost, već se dinamički računa, svrha je da se prilagodi različitim mrežnim uslovima.
RTO ima standardni metod računanja formule, zove se Jacobson / Karels algoritam.
①,Računanje SRTT (Smoothed RTT, glatkog vreme povratka), da bi se izbeglo uticaje vibracije jednog merenja na vreme ponavljanja.
SRTT = (1 - α) * SRTT + α * RTTGde je α konstanta, obično uzima vrednost 0.125 (tj. 1/8), označava proporciju uticaja novog merenja na glatko RTT.
RTT, to jest Round-Trip Time, vreme povratka, to jest vreme od slanja paketa do primanja potvrde. TCP će meriti RTT svakog paketa podataka i stalno ažurirati ovu vrednost.

②,Računanje RTTVAR (RTT Variation, označava varijaciju RTT, koristi se za merenje fluktuacije RTT-a)
RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|)β se obično uzima vrednost 0.25 (tj. 1/4), označava težinu ažuriranja RTTVAR.
③,Konačno, dobija se konačni RTO
RTO = SRTT + max(G, 4 x RTTVAR)G je mala konstanta ofset, koristi se da se spreči da RTO bude premalen. Opšte uzevši, vrednost G je obično 1 milisekunda.
Opšte uzevši, RTO je malo veće od RTT, efekat je najbolji.
- Ako je RTO veoma veliko, možda dugo čekati bez ponovnog slanja.
- Ako je RTO veoma malo, moguće je da podaci još nisu izgubljeni, a već počinju da se ponavljaju.
Timeout ponavljanje nije veoma dobro rešenje ponavljanja, ima sledeće nedostatke:
- Kada se segment izgubi, treba čekati određeni period timeout, zatim početi ponovno slanje.
- Kada se segment izgubi, u procesu čekanja timeout-a, može se desiti situacija: kasniji segmenti su već primljeni od strane primaoca, ali još uvek ne dobijaju potvrdu, pošiljalac će smatrati da su takođe izgubljeni, time dovodeći do nepotrebnog ponavljanja.
- I za TCP, ako se desi jedan timeout ponavljanje, sledeći interval vremena će se udvostručiti.
Što je brzo ponavljanje?
TCP ima još jedan mehanizam brzog ponavljanja (Fast Retransmit), ne vođen vremenom, već vođen podacima. Vođen je povratnim informacijama primaoca da pokrene ponavljanje.
Ne vođen vremenom, već vođen podacima. Bazira se na povratnim informacijama primaoca da pokrene ponavljanje.
Može se koristiti za rešavanje problema čekanja vremena pri timeout ponavljanju, proces brzog ponavljanja je kao što sledi:

Na gornjoj slici, pošiljalac je poslao 1, 2, 3, 4, 5 podataka:
- Prvi Seq1 prvo stigne, zato Ack vraća 2,
- Rezultat Seq2 iz nekog razloga nije stigao, Seq3 stigne, zato još uvek Ack vraća 2,
- Kasnije Seq4 i Seq5 su stigli, ali još uvek Ack vraća 2, zato što Seq2 još uvek nije stigao,
- Pošiljalac je primio tri Ack = 2 potvrde, znao je da Seq2 još uvek nije stiglo, će ponovo poslati izgubljeni Seq2 pre isteka tajmera.
- Konačno, primi Seq2, u ovom trenutku zato što Seq3, Seq4, Seq5 su svi primljeni, zato Ack vraća 6.
Mehanizam brzog ponavljanja rešio je samo jedan problem, to jest problem vremena timeout-a, ali i dalje se suočava sa drugim problemom. To jest problem pri ponavljanju, da li ponovo poslati prethodni jedan, ili ponovo poslati sve.
Na primer za gornji primer, da li ponovo poslati Seq2? ili ponovo poslati Seq2, Seq3, Seq4, Seq5? Zato što pošiljalac ne zna čija su tri dupla Ack 2 vraćena.
Prema različitim TCP implementacijama, oba slučaja su moguća. Vidi, ovo je dvostrani mač.
Da bi rešio problem nepoznavanja koje TCP segmente treba ponoviti, zato postoji SACK metod.
Što je ponavljanje sa selektivnom potvrdom (SACK)
Da bi rešio problem koliko paketa treba ponoviti? TCP pruža ponavljanje sa selektivnom potvrdom (tj. SACK, Selective Acknowledgment).
SACK mehanizam je, na osnovu brzog ponavljanja, primaoc vraća opseg brojeva sekvence najskorije primljenog segmenta, tada pošiljalac zna koje pakete primaoc nije primio. Tako je jasno koje pakete treba ponoviti.

Na gornjoj slici, pošiljalac je primio tri ista ACK potvrdna segmenta, tada će pokrenuti mehanizam brzog ponavljanja, kroz SACK informaciju otkriva da je samo 200~299 opseg podataka izgubljen, pri ponovnom slanju, bira samo ovaj TCP segment za ponovno slanje.
Što je duplo SACK (D-SACK)?
D-SACK, engleski je Duplicate SACK, neka proširenja na osnovu SACK-a, uglavnom služi da kaže pošiljaocu, koje pakete je primio duplo.
Svrha DSACK-a je pomoći pošiljaocu da proceni, da li se desilo otežanje paketa, gubitak ACK, dupli paketi ili lažno ponavljanje. Čini da TCP može bolje raditi mrežnu kontrolu toka.
Na primer gubitak ACK uzrokuje dupliranje paketa:

- Primaoc šalje dva ACK potvrdna segmenta pošiljaocu, oba su izgubljena, zato pošiljalac posle timeout-a ponovo šalje prvi paket (3000 ~
- Zato primaoc otkrije da su podaci duplo primljeni, zato vraća jedan SACK = 3000~3500, kaže „pošiljaocu“ 3000~3500 podataka su već davno primljeni, zato što su ACK već stigli do 4000, to znači da svi podaci pre 4000 su već primljeni, zato ovaj SACK predstavlja D-SACK. Tako pošiljalac zna, podaci nisu izgubljeni, već su potvrdni segmenti primaoca izgubljeni.
- Erge Programiranje Planeta član planete Zhen Yun Mian Meituan AI pitanje intervjua: Objasnite TCP mehanizam timeout ponavljanja
45.Kažite TCP lepljenje i cepanje paketa?
TCP lepljenje i cepanje je više koncept biznisa!
Što su TCP lepljenje i cepanje paketa?
TCP je orijentisan ka toku, nema granice niz podataka. TCP sloj ne razume konkretan značaj podataka gornjeg sloja biznisa, će se prema stvarnoj situaciji TCP bafera deliti pakete, zato u smislu biznisa, jedn complet paket može biti podeljen na više paketa za slanje od strane TCP, takođe moguće je da više malih paketa spakuje u jedan veliki paket za slanje, to je tzv. problem TCP lepljenja i cepanja paketa.

Zašto se dešava lepljenje i cepanje paketa?
- Podaci za slanje su manji od veličine TCP slanja bafera, TCP će jednokratno poslati podatke više puta upisane u bafer, dešavaće lepljenje,
- Sloj aplikacije primaoca nije vreme pročitao podatke u prijemnom baferu, dešavaće lepljenje,
- Podaci za slanje su veći od preostalog prostora TCP slanja bafera, dešavaće cepanje,
- Podaci za slanje su veći od MSS (maksimalna dužina segmenta), TCP će pre prenosa podeliti. To jest TCP dužina segmenta - TCP dužina zaglavlja > MSS.
Kako rešiti?
- Svaki paket podataka koji pošiljalac šalje encapsulate kao fiksnu dužinu
- Dodati specijalne karaktere na kraj podataka za deljenje
- Podeliti podatke na dva dela, jedan deo je zaglavlje, jedan deo je telo sadržaja, gde je veličina zaglavlja fiksna, i postoji polje koje deklariše veličinu tela sadržaja.
63.Koliko HTTP zahteva može poslati jedna TCP veza? (dopuna)
Dodano 24. maja 2024. godine
Koliko HTTP zahteva može poslati jedna TCP veza, zavisi od verzije HTTP protokola.
U HTTP/1.0, svaki HTTP zahtev-odgovor koristi zasebnu TCP vezu. To znači da se svaki put kada šaljete HTTP zahtev mora uspostaviti novu TCP vezu.
HTTP/1.1 uvodi trajnu vezu (Persistent Connection), podrazumevano dopušta slanje više HTTP zahteva na jednoj TCP vezi.
Postavljanjem Connection: keep-alive zaglavlja, veza se održava otvorenom dok se eksplicitno ne zatvori. Ovo drastično poboljšava efikasnost, jer nije potrebno uspostavljati novu vezu za svaki zahtev.
Dodatno, HTTP/1.1 podržava pipelining zahteva, dopušta klijentu da šalje više zahteva pre nego što primi prethodni odgovor.
HTTP/2 dodatno optimizuje multiplexing veze, dopušta istovremeno slanje više zahteva i odgovora na jednoj TCP vezi, ovi zahtevi i odgovori su podeljeni na frame-ove i prenose se kroz tokove. TCP multiplexing mehanizam HTTP/2 značajno poboljšava konkurentne performanse i efikasnost korišćenja resursa.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje drugog tehničkog intervjua kandidata 1 kompanije ByteDance: Koliko HTTP zahteva može poslati jedna TCP veza?
GitHub open-sorsna baza znanja sa preko 17.000 zvezdica "Ergov put napredovanja u Javi" prvo izdanje PDF konačno je stiglo! Uključuje osnovnu Java sintaksu, nizove&stringove, OOP, kolekcione okvire, Java IO, rukovanje izuzecima, nove Java osobine, mrežno programiranje, NIO, konkurentno programiranje, JVM itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Fantastično, Java tutorijal sa preko 17.000 zvezdica na GitHubu
UDP
UDP pitanja neću biti previše mnogo, uglavnom se upoređuje sa TCP-om.
46.Koja je razlika između TCP i UDP?
TCP je orijentisan ka vezi, dok UDP nije orijentisan ka vezi.

TCP je kao poziv jedan na jedan privatni ćaskanje, UDP je kao uzeti veliki zvučnik za emitovanje (😂).

Pre početka prenosa podataka, TCP mora prvo uspostaviti vezu, nakon completiranja prenosa podataka, zatim prekidati vezu. Ovaj proces se obično zove "trostruko rukovanje", "četvorostruko rukovanje".
UDP nije orijentisan ka vezi, ne treba uspostavljati vezu pre slanja podataka, nakon completiranja slanja ne treba prekidati, podatke šalje u obliku datagrama.
Drugim rečima: TCP je pouzdan, kroz mehanizam potvrde, mehanizam ponavljanja itd. osigurava pouzdan prenos podataka. A UDP nije pouzdan, paketi podataka mogu biti izgubljeni, duplirani, neuređeni.
Koja su primena TCP i UDP?
- TCP: Pogodan za situacije gje je tačnost podataka važnija od brzine prenosa podataka. Na primer: pretraživanje veba, e-pošta, prenos datoteka (FTP), daljinsko kontrolisanje, veza baze podataka.
- UDP: Pogodan za situacije gje su zahtevi za brzinom visoki, može se tolerisati određeni gubitak podataka. Na primer: QQ ćaskanje, online video, mrežni glasovni poziv, emitovanje komunikacije. Tolerisati određeni gubitak podataka.
Kako biste dizajnirali mrežni protokol QQ-a?
Prvo, treba realizovati funkciju prijavljivanja, to je prvi korak korišćenja QQ-a, da bi osigurali sigurnost naloga i lozinke, možemo izabrati TCP + SSL/TLS protokol za prijavljivanje.
Zato što je TCP protokol pouzdan protokol prenosa, može osigurati integritet podataka, a SSL/TLS može enkriptovati komunikaciju, osiguravajući sigurnost podataka.
Zatim, treba razmisliti o realnosti prenosa poruka, kao glasovni i video pozivi itd., u ovom trenutku možemo izabrati UDP protokol. Brzina prenosa UDP-a je brža, za real-time servise je brzina najvažnija.
Kako osigurati da se poruke ne gube?
Za TCP protokol, ako se paket izgubi u procesu prenosa, TCP protokol će automatski ponoviti slanje.
Za UDP protokol, možemo kroz mehanizam ponavljanja na sloju aplikacije osigurati da se poruke ne gube. Kada primaoc primi poruku, vrati potvrdnu informaciju pošiljaocu, ako pošiljalac u određenom vremenu ne primi potvrdnu informaciju, ponovo šalje poruku.
Istovremeno, svaka poruka nosi jedinstven broj sekvence, primaoc prema broju sekvence procenjuje da li ima gubitak poruka, ako otkrije da brojevi sekvence nisu kontinuirani, može zatražiti od pošiljaoca da ponovo pošalje. Takođe može sprečiti dupliranje poruka.
Naravno, trajnost poruka je takođe veoma važna, može se čuvati poruku na serveru ili lokalnoj bazi podataka, čak i u slučaju prekida mreže ili drugih abnormalnih situacija, može se oporaviti poruka iz baze podataka.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua kompanije Huawei: Kažite razliku između TCP i UDP?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 1 kompanije QiAnXin za Java razvoj: Koja je razlika između tcp i udp? Koji protokol QQ koristi? Kako osigurava da se poruke ne gube?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 6 kompanije China Merchants Bank: Koja je razlika između UDP i TCP?
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje intervjua kandidata 9 kompanije Dewu: Predstavite tcp i udp protokol u računarskim mrežama
47.Zašto QQ koristi UDP protokol?
PS: Ovo je staro pitanje iz pre mnogo godina, izvučeno da se sećamo.

- Prvo, QQ nije kompletno baziran na UDP realizaciji. Na primer, kada koristite QQ za prenos datoteka i druge aktivnosti, će koristiti TCP kao garanciju pouzdanog prenosa.
- Prednost korišćenja UDP za interaktivnu komunikaciju je u kraćem kašnjenju, jednostavnije rukovanje gubitkom podataka. Istovremeno, TCP je protokol punog duplex-a, treba uspostaviti vezu, zato mrežni troškovi će biti relativno veći.
- Ako koristite QQ glas i QQ video, prednost UDP-a je još izraženija, pre svega kraće kašnjenje. Najvažnija tačka je nepouzdan prenos, to znači ako se podaci izgube, neće biti ponovljenog slanja. Zato što korisnici opšte mogu prihvatiti da je slika malo nejasna, zvuk malo nejasan, ali ako se pre nekoliko sekundi pojave prethodno izgubljeni slike i zvuci, ovo je verovatno teško prihvatiti.
- Zato što je dizajn kapaciteta QQ servera na nivou masivne aplikacije, jedan server istovremeno može da primi više od deset hiljada konkurentnih veza, zato samo server strana može koristiti UDP protokol za komunikaciju sa klijentom da bi osigurala ovakvu super-veliku skalabilnost servisa
Jednostavno sažetak: UDP protokol je protokol bez načina povezivanja, visoka efikasnost, brza brzina, malo trošenje resursa, pritisak na server je manji. Ali njegov mehanizam transmisije je nepouzdan, mora se oslanjati na pomoćne algoritme da completira transmisiju kontrolu. QQ koristi komunikacioni protokol uglavnom UDP, uz pomoć TCP protokola.
48.Zašto je UDP protokol nepouzdan?
UDP pre slanja podataka ne treba prvo uspostaviti vezu, transportni sloj udaljenog hosta nakon primanja UDP datagrama ne treba potvrditi, pruža nepouzdanu isporuku. Sažeto u sledeća četiri tačke:
- Ne garantuje isporuku poruke: ne potvrđuje, ne ponavlja, nema timeout
- Ne garantuje redosled isporuke: ne postavlja broj sekvence paketa, ne ponovo uređuje, neće desiti se head-of-line blokada
- Ne prati status veze: ne mora uspostaviti vezu ili restartovati state machine
- Ne vrši kontrolu zagušenja: nema ugrađeni mehanizam povratne informacije klijenta ili mreže
49.Zašto DNS koristi UDP?
Precnije rečeno, DNS koristi i TCP i UDP.
Kada se vrši zonalni prenos (glavni domen server šalje deo promenjenih podataka pomoćnom domen serveru) će se koristiti TCP, zato što je količina podataka sinhronizacije veća od količine podataka jednog zahteva i odgovora, a TCP dozvoljava dužinu segmenata, zato će se koristiti TCP baziran na pouzdanoj vezi za osiguranje ispravnosti podataka.
Kada klijent upituje domen server (rezolucija domena), opšte se vraćeni sadržaj neće premašivati maksimalnu dužinu UDP datagrama, to jest 512 bajtova, korišćenje UDP prenosa ne treba kreirati vezu, time značajno poboljšava brzinu odgovora, ali to zahteva da domen rezolucioni server i domen server moraju sami da rešavaju timeout i ponovno slanje da bi osigurali pouzdanost.
GitHub open-sorsna baza znanja sa preko 17.000 zvezdica "Ergov put napredovanja u Javi" prvo izdanje PDF konačno je stiglo! Uključuje osnovnu Java sintaksu, nizove&stringove, OOP, kolekcione okvire, Java IO, rukovanje izuzecima, nove Java osobine, mrežno programiranje, NIO, konkurentno programiranje, JVM itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Fantastično, Java tutorijal sa preko 17.000 zvezdica na GitHubu
IP
50.Definicija i uloga IP protokola?
IP protokol (Internet Protocol) koristi se za prenos paketa podataka između računarskih mreža, definiše format paketa podataka i pravila obrade, osigurava da se podaci mogu preneti sa jednog uređaja na drugi, mogu proći kroz više uređaja između mreža (kao ruteri).

Koje su uloge IP protokola?
①,Adresiranje: Svaki uređaj povezan na mrežu ima jedinstvenu IP adresu. IP protokol koristi ove adrese da identifikuje izvornu i odredišnu adresu paketa podataka, osiguravajući da se paketi podataka tačno prenose na ciljni uređaj.
②,Rutiranje: IP protokol je zadužen za odlučivanje puta prenosa paketa podataka u mreži. Na primer, ruter koristi rutirajuću tablicu i IP adrese informacija da odredi najbolju putanju prenosa paketa podataka.
③,Fragmentacija i reasemblacija: Kada je paket prevelik da ne može proći kroz određenu mrežu, IP protokol će podeliti paket na manje fragmente za prenos. Primaoc će reasemblirati ove fragmente u kompletan paket prema informacijama zaglavlja.
Dajte konkretnan primer za objašnjenje?
Pretpostavimo da postoji dva uređaja A i B koji komuniciraju kroz internet, IP adresa uređaja A je 192.168.1.1, IP adresa uređaja B je 203.0.113.5. Proces transmisije paketa podataka je kao što sledi:
①,Uređaj A šalje paket podataka:
- Uređaj A kreira IP paket podataka, postavlja izvornu adresu na 192.168.1.1, odredišnu adresu na 203.0.113.5, stavlja podatke koje treba preneti u deo podataka.
- Nakon encapsulacije paketa podataka, šalje se na ruter kroz lokalnu mrežu.
②,Ruter prosleđuje paket podataka:
- Ruter prema rutirajućoj tablici traži odredišnu adresu 203.0.113.5, određuje transmisijinu putanju paketa podataka.
- Paket podataka može proći kroz više međuređaja, svaki ruter bira sledeći skok prema rutirajućoj tablici, konačno stiže do mreže ciljnog uređaja.
③,Uređaj B prima paket podataka:
- Uređaj B primi paket podataka, čita informacije IP zaglavlja, verifikuje integritet paketa podataka.
- I izvlači deo podataka, daje sloju iznad (kao TCP ili UDP) za obradu.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog intervjua stažisti kandidata 12 kompanije Huawei: Kažite nešto o IP protokolu.
51.Koja su klasifikacija IP adresa?
Jedna IP adresa je jedinstvena u opsegu celog interneta, opšte se može smatrati, IP adresa = {<broj mreže>, <broj hosta>}.
- Broj mreže: Označava adresu mreže kojoj host pripada, označava kojoj mreži interneta pripada.
- Broj hosta: Označava adresu hosta, označava kojem hostu u toj mreži pripada.
IP adrese se dele na A, B, C, D, E pet velikih kategorija:
- A klasa adresa (1~126): Počinje sa 0, broj mreže zauzima prvih 8 bitova, broj hosta zauzima poslednjih 24 bitova.
- B klasa adresa (128~191): Počinje sa 10, broj mreže zauzima prvih 16 bitova, broj hosta zauzima poslednjih 16 bitova.
- C klasa adresa (192~223): Počinje sa 110, broj mreže zauzima prvih 24 bitova, broj hosta zauzima poslednjih 8 bitova.
- D klasa adresa (224~239): Počinje sa 1110, rezervisano je za multicast adresu.
- E klasa adresa (240~255): Počinje sa 1111, rezervisano je za buduću upotrebu

52.Koja je veza između domena i IP? Može li jedna IP odgovarati više domena?
- IP adresa je jedinstvena u istoj mreži, koristi se za identifikaciju svakog uređaja na mreži, odgovara ličnom broju građana
- Domen je takođe jedinstven u istoj mreži, kao ime, nadimak osobe
Ako imaš više nadimaka, prijatelji mogu zvati bilo kojim nadimkom, ali tvoj lični broj je jedinstven. Ali tvoj nadimak se može poklapati sa drugim ljudima, ako te nema, neko zove tvoj nadimak, drugi ljudi mogu odgovoriti.
Jedan domen može odgovarati više IP adresa, ali ovo je DNS load balansiranje, u procesu pristupa korisnika, jedan domen može odgovarati samo jednoj IP adresi.
A jedna IP može odgovarati više domena, je odnos jedan prema više.
53.Kako rešiti nedostatak IPV4 adresa?
Znamo da IP adresa ima 32 bita, može označiti 2 na 32 stepena adresa, zvuči mnogo, ali broj mrežnih uređaja globalno je daleko premašio ovaj broj, zato IPV4 adresa više nije dovoljna, kako rešiti?

- DHCP: Dinamički protokol konfiguracije hosta, dinamički dodeljuje IP adresu, samo dodeljuje IP adresu uređajima koji pristupaju mreži, zato isti uređaj sa istom MAC adresom svaki put kada pristupa internetu ne dobija nužno istu IP adresu, ovaj protokol omogućuje da slobodne IP adrese budu dobro iskorišćene.
- CIDR: Classless Inter-Domain Routing. CIDR eliminiše koncept tradicionalnih A, B, C klasa adresa i podele na podmrežu, stogo efikasnije dodeljuje adresni prostor IPv4, ali ne može temeljno rešiti problem iscrpljenosti adresa.
- NAT: Network Address Translation protokol, znamo da hostovi u različitim lokalnim mrežama mogu koristiti istu IP adresu, time donekle olakšavaju problem iscrpljenosti IP resursa, ali IP adresa koju host koristi u lokalnoj mreži ne može se koristiti u javnoj mreži, kada host u lokalnoj mreži želi da komunicira sa hostom u javnoj mreži, NAT metoda može konvertovati IP adresu tog hosta u globalnu IP adresu. Ovaj protokol može efikasno rešiti problem nedostatka IP adresa.
- IPv6: Kao sledeća generacija internetskog protokola naslednik IPv4, može ostvariti 2 na 128 stepena adresa, ovaj nivo, čak i dodeliti IP adresu svakom zrnu peska na Zemlji je dovoljno, ovaj protokol može temeljno rešiti problem nedostatka IPv4 adresa.
54.Kažite proces rada ARP protokola?
ARP (Address Resolution Protocol, protokol za rezoluciju adresa) je jedan protokol u mrežnoj komunikaciji, glavna svrha je da pretvori IP adresu mrežnog sloja u MAC adresu sloja veze.

①,ARP zahtev
Kada host A želi da pošalje podatke hostu B, prvo će potražiti MAC adresu hosta B u svojoj ARP keš memoriji.
Ako nije pronašao, host A će emitovati ARP zahtevni paket na mrežu, tražeći od svih hostova u mreži da kažu svoje MAC adrese, ovaj zahtev uključuje IP i MAC adresu uređaja zahteva i ciljnog uređaja.
②,ARP odgovor
Svi hostovi u mreži će primiti ovaj ARP zahtev, ali samo host B će odgovoriti ARP odgovor, reći hostu A svoju MAC adresu.
I host B će sačuvati mapiranje IP i MAC adrese hosta A u svoju ARP keš memoriju, kako bi sledeći put mogao direktno koristiti.
③,Ažuriranje ARP keša
Host A primi ARP odgovor hosta B, takođe će sačuvati mapiranje IP i MAC adrese hosta B u svoju ARP keš memoriju.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 7 kompanije Kuaishou za Java backend: Kažite proces ARP protokola
55.Zašto postoji i IP adresa i MAC adresa?
Koje su uloge MAC adrese i IP adrese?
- MAC adresa je adresa koju koriste sloj veze podataka i fizički sloj, to je fizička adresa napisana na mrežnoj kartici, koristi se za definisanje lokacije mrežnog uređaja, ne može se promeniti.
- IP adresa je adresa koju koriste mrežni sloj i slojevi iznad, to je logička adresa. IP adresa se koristi za razlikovanje računara na mreži.
Zašto postoji IP adresa pored MAC adrese?
Ako koristimo samo MAC adresu za adresiranje, treba da ruter pamti MAC adresu svakog podmreža, inače svaki put kada ruter primi paket podataka mora tragati za ciljnom MAC adresom širom sveta. A znamo da je dužina MAC adrese 48 bitova, to jest najviše postoji 2 na 48 stepena MAC adresa, to znači da svaki ruter treba 256T memorije, očigledno nije realno.
Iz različitih MAC adresa, IP adresa je povezana sa geografskim regionom, u jednoj podmreži uređajima, IP adresa koja im dodeljujemo ima isti prefix, tako da ruter može prema prefixu IP adrese znati kojoj podmreži pripada uređaj, preostalo adresiranje se prepušta unutrašnjoj realizaciji podmreže, time značajno smanjuje memoriju koju ruter zahteva.
Zašto postoji MAC adresa pored IP adrese?

- Samo kada uređaj pristupi mreži, može se dodeliti IP adresa prema podmreži u kojoj je ušao, pre ili u procesu dodele IP adrese. Treba nam MAC adresa da razlikujemo različite uređaje.
- IP adresa može se uporediti sa adresom, MAC adresa je primaoc, u jednom procesu komunikacije, obe strane su neophodne.
56.Koje su funkcije ICMP protokola?
ICMP (Internet Control Message Protocol), protokol kontrole poruka interneta.
- ICMP protokol je jedan protokol bez povezivanja, koristi se za prenos izveštaja o greškama i kontrolnih informacija.
- To je veoma važan protokol, ima izuzetno važan značaj za mrežnu bezbednost. Pripada mrežnom sloju protokola, uglavnom se koristi za prenos kontrolnih informacija između hosta i rutera, uključujući prijavu greške, razmenu ograničenih kontrolnih i statusnih informacija itd.
- Kada se desi da IP podatak ne može da stigne do odredišta, IP ruter ne može da prosledi paket podataka prema trenutnoj brzini prenosa itd., automatski će poslati ICMP poruku.
Na primer, često koristimo ping, to je bazirano na ICMP.
57.Kažite princip ping-a?
Ping, Packet Internet Groper, jedan mrežni alat, uglavnom se koristi za testiranje dostupnosti i kašnjenja mrežne veze.

Proces ping-a se uglavnom bazira na ICMP (Internet Control Message Protocol, protokol kontrole poruka interneta), njegov osnovni proces uključuje:
①,Kada se izvrši ping naredba, na primer ping javasi.dev, ping prvo rešuje domen da dobije IP adresu, zatim šalje ICMP Echo Request poruku na ciljnu IP adresu.
②,Kada ciljna IP prima ICMP Echo Request poruku, generisaće ICMP Echo Reply poruku i vratiću, to jest ping odgovor poruku.
③,Uređaj koji je pokrenuo ping naredbu primi ICMP Echo Reply poruku, izračuna i prikaže vreme od slanja Echo Request do primanja Echo Reply (obično nazvano Round-Trip Time, RTT), kao i eventualne informacije o gubitku paketa.
Ping obično šalje više zahteva, kako bi pružio prosečno vreme odgovora i stopu gubitka paketa itd., kako bismo razumeli kvalitet mrežne veze.
- Vodič za razgovor o Javi (plaćeno) uključuje pitanje prvog tehničkog intervjua kandidata 7 kompanije Kuaishou za Java backend: Kažite proces ping-a
GitHub open-sorsna baza znanja sa preko 17.000 zvezdica "Ergov put napredovanja u Javi" prvo izdanje PDF konačno je stiglo! Uključuje osnovnu Java sintaksu, nizove&stringove, OOP, kolekcione okvire, Java IO, rukovanje izuzecima, nove Java osobine, mrežno programiranje, NIO, konkurentno programiranje, JVM itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Fantastično, Java tutorijal sa preko 17.000 zvezdica na GitHubu
Mrežna bezbednost
58.Koje su sigurnosni napadi?
Mrežni sigurnosni napadi se uglavnom dele na dve vrste, pasivni napad i aktivan napad:

Pasivni napad: Napadač prisluškuje komunikacioni sadržaj drugih na mreži, obično ovu vrstu napada zovu presretanje, pasivni napadi imaju dva glavna oblika: napad na curenje sadržaja poruke i napad na analizu prometa. Zato što napadač nije menjao podatke, ovaj napad je teško detektovati.
Aktivan napad: Direktno utiče na postojeće podatke i servise, uobičajeni tipovi aktivnih napada su:
Falsifikovanje: Napadač namerno menja segmente poslate na mreži, čak šalje completirano falsifikovane segmente primaocu.
Zlonamerni program: Vrste zlonamernih programa su mnogobrojni, uključujući računarski virus, računarski crv, Trojanski konj, zadnja vrata, zlonameran softver itd.
Odbijanje servisa DoS: Napadač neprestano šalje segmente na server, čineći da server ne može pružiti normalni servis.
59.Znate li DNS otmicu?
DNS otmica, to jest otmica domena, vrši se zamjenom IP adrese koja odgovara originalnom domenu, čineći da korisnik pristupa pogrešnom veb sajtu, ili korisnik ne može normalno pristupiti veb sajtu, to je jedan način napada.

Otmica domena često može biti izvršena samo u određenom mrežnom opsegu, izvan opsega DNS server može vratiti normalnu IP adresu. Napadač može se lažno predstaviti kao organizacija koja poseduje domen, putem e-pošte menja informacije o registraciji domena, ili prenosi domen drugoj strani, i čuva novu informaciju o domenu u specificiranom DNS serveru, time čineći da korisnik ne može da vrši rezoluciju originalnog domena da bi pristupio ciljnoj adresi.
Koji su koraci DNS otmice?
- Dobavljanje informacija o domeni koji treba otkrati: Napadač će prvo posetiti upit domene da sazna informacije o sajtu koji treba otkrati.
- Kontrola E-Mail naloga koji odgovara na domen: Nakon dobijanja informacija o domeni, napadač će kroz brute-force ili specijalne metode probiti lozinku E-Mail naloga korišćenog pri registraciji domena kompanije, napredniji napadači mogu čak direktno izvršiti krađu informacija E-Mail-a.
- Menjanje registracionih informacija: Kada napadač probije E-Mail, koristi relevantne funkcije izmene da menja registracione informacije domena, uključujući informacije o vlasniku domena, informacije o DNS serveru itd.
- Korišćenje E-Mail za primanje i slanje potvrdne poruke: Nakon menjanja registracionih informacija, napadač E-Mail pre pravog vlasnika prima relevantne informacije o potvrdi menjanja registracije domena, i odgovara na potvrdu o izmeni fajla, nakon što mrežna kompanija vrati uspešnu izmenu poruke, napadač uspešno completira DNS otmicu.
Kako se odupreti DNS otmici?
- Direktno pristupite veb sajtu putem IP adrese, izbegavajte DNS otmicu
- Zato što DNS otmica često može biti izvršena samo u određenom mrežnom opsegu, stoga neki napredni korisnici mogu kroz mrežna podešavanja postaviti DNS da upućuje na normalni DNS server (kao što je 8.8.8.8) da realizuju normalni pristup ciljnom URL-u
60.Što je CSRF napad? Kako izbegnuti?
Što je CSRF napad?
CSRF, Cross-Site Request Forgery, tj. falsifikovanje zahteva sa drugog sajta, je jedan metod napada koji korisnika, koji je trenutno prijavljen na veb aplikaciji, izvršava nenamerene operacije.
Kako CSRF napada?
Pogledajmo jedan primer:

- Korisnik se prijavio na banku, nije se odjavio, pretraživač sadrži informacije o autentifikaciji korisnika u banci.
- Napadač lažira prenosni zahtev, uključuje ga u post
- Korisnik u situaciji održavanja prijave na veb sajtu banke, pregleda post
- Šalje lažirani prenosni zahtev zajedno sa informacijama o autentifikaciji na veb sajt banke
- Veb sajt banke vidi informacije o autentifikaciji, smatra da je to legitimna operacija korisnika, konačno dovodi do gubitka sredstava korisnika.
Kako se odupreti CSRF napadu?
- Provera Referer polja
Referer polje u HTTP zaglavlju čuva izvornu adresu HTTP zahteva. U uobičajenim uslovima, zahtev za pristup stranici sa ograničenjem bezbednosti dolazi sa istog sajta, a ako haker želi da izvrši CSRF napad, opšte može konstruisati zahtev na svom sajtu. Zato se može braniti od CSRF napada proverom Referer vrednosti.
- Dodajte proveru token-a
U HTTP zahtev se može dodati nasumično generisani token kao parametar, i na serveru postaviti interceptor da proveri ovaj token, ako u zahtevu nema token ili sadržaj token-a nije ispravan, smatra se da je moguća CSRF napad i odbija ovaj zahtev.
- Višestruka provera osetljivih operacija
Za neke osetljive operacije, pored provere informacija o autentifikaciji korisnika, može se kroz e-potvrdu, proveru verifikacionog koda itd. metoda višestruke provere.
61.Što su DoS, DDoS, DRDoS napadi?

- DOS: (Denial of Service), prevodeno je odbijanje servisa, svi napadi koji mogu izazvati odbijanje se zovu DOS napadom. Uobičajeni DoS napadi uključuju napad na mrežni širinu prenosa računarske mreže, napad na povezivost.
- DDoS: (Distributed Denial of Service), prevodeno je distribuirano odbijanje servisa. To znači da više napadača na različitim lokacijama simultano napada jedan ili nekoliko ciljeva, ili jedan napadač kontroliše više mašina na različitim lokacijama, i koristi te mašine da simultano izvrši napad na žrtve.
Glavni oblici su napad na promet i napad na iscrpljivost resursa, uobičajeni DDoS napadi uključuju: SYN Flood, Ping of Death, ACK Flood, UDP Flood itd.
- DRDoS: (Distributed Reflection Denial of Service), kineski je distribuirano reflektivno odbijanje servisa, ovaj način se oslanja na slanje velikog količine paketa sa IP adresom žrtve na napadnuti host, zatim napadnuti host odgovara velikim količinama na IP adresu izvora, time formirajući napad odbijanja servisa.
Kako se braniti od DDoS-a?
Za napad na promet DDoS-a, najdirektniji metod je povećanje propusnog pojasa, teorijski dok je propusni pojam veći od napadačkog prometa, ali ovaj metod je veoma skup. U uslovima adekvatnog propusnog pojasa, treba što više poboljšati konfiguraciju hardvera rutera, mrežne kartice, prekidača i druge hardverske infrastrukture.
Za napad na iscrpljivost resursa, možemo nadograditi hardver servera, u uslovima garancije mrežnog propusnog pojama, omogućiti serveru da efikasno nosi sa masovnim SYN napadnim paketima. Takođe možemo instalirati profesionalni DDoS firewall, da se nosi sa SYN Flood i drugim tipovima napada na promet. Vatrogenci, load balansiranje, CDN itd. tehnologije mogu efikasno boriti protiv DDos napada.
62.Što je XSS napad, kako izbeguci?
XSS napad je takođe relativno uobičajen, XSS, zove se Cross-Site Scripting (kros-sajt skriptni napad), zato što će se zbuniti sa skraćenicom CSS stilova (Cascading Style Sheets, CSS), neki ga zovu XSS napad. To znači da zlonamerani napadač ubacuje zlonameran HTML kôd u veb stranicu, kada korisnik pregleda veb stranicu, HTML kôd ugrađen u veb će biti izvršen, time dostižući specifični cilj zlonamernog napada na korisnika.
XSS napadi se opštem dele na tri tipa: smeštajući , reflektujući , DOM tip XSS
Kako XSS napada?
Jednostavno rečeno, način XSS napada je pokušati "navoditi" pretraživač korisnika da izvrši neke front-end kodove koji ne postoje u ovoj veb stranici.
Uzmi reflektujući kao primer, procesni dijagram je kao što sledi:
- Napadač konstruiše specijalni URL, koji sadrži zlonameran kôd.
- Korisnik otvara URL sa zlonameranim kodom, pristupa normalnom veb serveru
- Server veba izvlači zlonameran kod iz URL-a, spaja u HTML i vraća ga pretraživaču.
- Pretraživač klijenta primi odgovor i počne da analizira i izvršava, mešani zlonameran kod je takođe izvršen, šalje podatke korisnika zlonameranom serveru
- Napadač može ukrasti podatke korisnika, time predstavlja ponašanje korisnika, poziva ciljni veb interfejs da izvrši operacije koje je odredio napadač.

Kako se odupreti XSS napadu?
- Filtrirati ulaz, filtrirati tagove itd., dozvoliti samo legitimne vrednosti.
- HTML escape
- Za link skok, kao što je
<a href="xxx"itd., treba proveriti sadržaj, zabraniti ilegalne linkove koji počinju sa script-a. - Ograničiti dužinu unosa
63.Koja je razlika između simetrične i asimetrične enkripcije?
Simetrična enkripcija: Označava da se enkripcija i dekritpcija koriste isti ključ, prednost je brza brzina računanja, mana je kako bezbedno preneti ključ drugoj strani. Uobičajeni algoritmi simetrične enkripcije su: DES, AES itd.

Asimetrična enkripcija: Označava da se enkripcija i dekritpcija koriste različite ključeve (tj. javni ključ i privatni ključ). Javni ključ i privatni ključ postoje u parovima, ako se koristi javni ključ za enkripciju podataka, samo odgovarajući privatni ključ može dekritpovati. Uobičajeni algoritmi asimetrične enkripcije su RSA.

64.Koja je razlika između RSA i AES algoritama?
- RSA
Koristi asimetrični način enkripcije, koristi javni ključ za enkripciju, privatni ključ za dekritpciju. Dužina privatnog ključa je opšte duža, zato što zahteva velike brojevane operacije stepena i modula, brzina računanja je spora, nije pogodna za enkripciju velikih datoteka.
- AES
Koristi simetrični način enkripcije, dužina ključa je najviše 256 bitova, brzina enkripcije i dekritpcije je brža, lako se realizuje u hardveru. Zato što je simetrična enkripcija, pre podrške prenosa podataka stranke treba da znaju enkripcioni ključ.
Ništa me ne može zadržati — osim cilja, čak i ako na obali ima ruža, hlad, mirna luka, ja sam brod bez sidra.
Serijski sadržaj:
- Povratak intervjua Java SE poglavlje 👍
- Povratak intervjua Java kolekcioni okvir poglavlje 👍
- Povratak intervjua Java konkurentno programiranje poglavlje 👍
- Povratak intervjua JVM poglavlje 👍
- Povratak intervjua Spring poglavlje 👍
- Povratak intervjua Redis poglavlje 👍
- Povratak intervjua MyBatis poglavlje 👍
- Povratak intervjua MySQL poglavlje 👍
- Povratak intervjua Operativni sistemi poglavlje 👍
- Povratak intervjua Računarske mreže poglavlje 👍
- Povratak intervjua RocketMQ poglavlje 👍
- Povratak intervjua Distribuirani sistemi poglavlje 👍
- Povratak intervjua Mikroservisi poglavlje 👍
- Povratak intervjua Dizajn paterni poglavlje 👍
- Povratak intervjua Linux poglavlje 👍
- Povratak intervjua OpenClaw poglavlje 👍
- Povratak intervjua Skills poglavlje 👍
GitHub open-sorsna baza znanja sa preko 17.000 zvezdica "Povratak intervjua" drugo izdanje PDF konačno je stiglo! Uključuje osnovu Jave, Java kolekcioni okvir, Java konkurentno programiranje, JVM, Spring, Redis, MyBatis, MySQL, operativni sistemi, računarske mreže, RocketMQ, distribuirani sistemi, mikroservisi, dizajn paterni, Linux, OpenClaw itd., ukupno preko 320.000 reči, preko 500 ručno crtanih crteža, može se reći da je razumljivo, zanimljivo i humoristično... Detalji: Povratak intervjua 2.0 izdanje PDF objavljeno, obavezno čitanje za Java backend programere, možda najbolje "osam grožđ" za 2026. godinu
