I know the TCP protocol binds itself to a port till the transfer of messages is over (port 80)
Una connessione TCP è identificata in modo univoco dalla tupla a quattro (indirizzo di origine, porta di origine, indirizzo di destinazione, porta di destinazione). Gli indirizzi IP di origine e destinazione si prenderanno cura di loro stessi, ma tu sei leggermente confuso riguardo alle porte.
Una porta è solo un numero intero a 16 bit, usato per distinguere tra più socket attivi sullo stesso host, ma ci sono alcune convenzioni che governano la loro allocazione ( riferimento: wikipedia ):
-
Le "ben note" porte sono < 1024.
Come hai notato, 80 è la porta "ben conosciuta" per HTTP, il che significa che è l'impostazione predefinita a meno che il tuo URL non specifichi diversamente. Queste porte sono generalmente protette dal sistema operativo, quindi un processo non privilegiato non può vincolare uno e quindi mascherarsi come un servizio ben noto.
- le porte "registrate", utilizzabili da processi non privilegiati per fornire servizi, sono comprese tra 1024 e 49152. Ad esempio, 8080 è comunemente utilizzato per un server HTTP non privilegiato
- i valori rimanenti da 49152 a 65535 vengono utilizzati per le porte effimere . Quando si crea un socket e si connette a un server, senza vincolare il socket a una particolare porta locale, il kernel assegna una porta libera dall'intervallo effimero. Questo è solo per creare una singola tupla in 4 che identifica la tua connessione, e di solito non ti interessa mai quale sia il valore.
- NB. la portata effettiva utilizzata per le porte effimere può variare a seconda del sistema operativo e può anche essere configurata, tuttavia inizierà sempre al di sopra di 1024.
and UDP is best effort (ie no binding).
UDP sta per User Datagram Protocol . Hai ragione che è lo sforzo migliore, ma questo non ha nulla a che fare con le porte. Sia TCP che UDP utilizzano esattamente lo stesso schema di indirizzamento IP, con la stessa 4-tupla. Probabilmente non lo userai mai per HTTP (vedi la risposta alla tua ultima domanda di seguito).
My question is if I try and access two websites at the same time (multiple tabs on my browser), assuming both websites are web servers, my questions are
- Does my computer communicate with one webservice (website) first and then communicate with the other (serially). Also if this is the case is the time difference so small that I feel it loads simultaneously?
Sì e no. Crei due socket e li colleghi entrambi. L'IP di origine sarà lo stesso per ciascuno (poiché si trovano sullo stesso computer e presumibilmente utilizzano la stessa interfaccia di rete su quella macchina). L'IP e la porta di destinazione saranno gli stessi (si collegano allo stesso server HTTP). Tuttavia, la porta di origine sarà diversa, perché il tuo sistema operativo ha assegnato una porta temporanea diversa a ciascun socket.
Poiché ogni socket è il tuo endpoint per una diversa connessione TCP (hanno diverse tuple da 4 uniche), possono essere eseguite in parallelo. Tuttavia, supponendo che le due connessioni siano sopra la stessa interfaccia di rete fisica, non possono inviare o ricevere pacchetti fisici contemporaneamente. In pratica ciò non ha importanza, dal momento che il sistema operativo interleave i loro pacchetti sulla rete fisica per te.
Le connessioni saranno generalmente asincrone, quindi entrambi i socket possono avere richieste in volo contemporaneamente e le risposte possono anche essere intercalate.
- Suppose I have my own web server (tomcat) running on port 80, how can I communicate with other websites if it happens on the same port?
Il tuo sito web ascolterà sull'IP, port tuple (localhost, 80). Se ci si connette allo stesso computer, la connessione sarà simile a (localhost, effimero1, localhost, 80). Se ci si connette a un server Web su un altro computer, la connessione sarà simile a (localhost, effimero2, host remoto, 80). Sono ancora diversi, anche se entrambi hanno un 80 in uno dei 4 valori.
L'unica cosa che non puoi fare è avere due diversi server web che ascoltano la porta 80 sulla stessa macchina.
- Do websites decide which protocol to use TCP or UDP?
Puoi sempre controllare tu stesso questa roba: lo standard è qui . Ecco la sezione pertinente:
HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope
of this specification.
Quindi vedi HTTP non avere per usare TCP, ma fa assume un protocollo affidabile (e orientato alla connessione), quindi UDP è fuori.