Witam,
Jaki jest nr portu do komunikacji HTTP po stronie klienta? Czy jest on dobierany z zakresu 49152 do 65535?
0
1
A to HTTP otwiera jakieś porty lokalnie?! To przecież nie FTP. Poza tym ciężko by było wtedy wielu osobom za NAT'em odwiedzać najprostsze strony internetowe. Poza tym jeśli chodzi Ci o news niebezpiecznika. Jeżeli nie masz modelu opisanej płyty. To jesteś raczej pod tym kątem bezpieczny. A jeśli ją masz to ten artykuł, o ile kojarzę, opisuje co robić.
0
Dziękuję za szybką odpowiedź. Mam niedługo zaliczenie z sieci komputerowych i takie pytanie pojawiło się we wcześniejszych latach. Nie chciałbym strzelić żadnej gafy na egzaminie.
0
Proszę bardzo. Ale może ktoś jeszcze tutaj coś więcej Tobie podpowie. Nie chcę uchodzić za eksperta, bo nim nie jestem. Najprościej po prostu pogooglować i poczytać sobie o protokole HTTP. Na pewno informacji jest mnóstwo.
0
Szukałem i trafiłem na identyczny temat: http://stackoverflow.com/questions/3400958/what-port-does-httpclient-use Jednak chcialem mieć pewność, ze te informacje są prawdziwe.
1
Pewne rzeczy jak użycie portu 80 do połaczenia po HTTP i 443 dla HTTPS są tak oczywiste, że raczej nie mogą być przekłamane. Ponieważ pewne rzeczy przy tak popularnym protokole, muszą być - o ile się orientuje - zgodne z RFC. Oczywiście nic nie szkodzi na przeszkodzie aby serwer pracował na porcie egzotycznym jak 666. Z tym, że wtedy będzie należało podac go w adresie, bo przeglądarki www domyślnie łączą się ze wspomianymi w pierwszym zdaniu tego posta.
2
Ale jeżeli chodzi o port klienta, to oczywiście, jak w przypadku każdego połączenia TCP, wybierany jest losowy port z zakresu zależnego od systemu operacyjnego. IANA faktycznie zaleca od 49152 do 65535.
1
Ale wy chyba mylicie port servera z portem klienta. Port musi być otwarty z obu stron! Port serwera http to zwykle 80 albo 8080, ale klient po swojej stronie prowadzi komunikację do dowolne wylosowanym porcie efemerycznym!
No bo przeciez jak przychodzi pakiet do komputera to OS musi jakoś ogarnąć do której aplikaci go wysłać. Jak odpalasz stronę www to wysyłasz żądanie na port 80 a odpowiedź dostajesz na ten wylosowany przez przeglądarkę port, bo inaczej OS nie wiedziałby komu ten pakiet przekazać.
0
Mogę się mylić. Nie jestem ekspertem w protokołach. Nigdy nie zagłębiałem się w meandry HTTP, bo nie musiałem. Trzeba było to korzystałem i tyle. Same podstawowe rzeczy są banalne do tego by zrobić prostego klienta. Port, o którym wspomina poprzednik nie jest jeśli się dobrze orientuje tym samym co port dla na przykład protokołu FTP. Który nie wymaga go tylko w trybie pasive. Ponieważ analogicznie rozumuje tak, że gdybyśmy musieli otwierać port lokalnie do komunikacji, tak jak robią to klienty FTP. To jak wspomniałem, mnóstwo osób za NAT'em lub bez odpowiedno przekierowanych portów na ruterze. Czy u ISP albo przez Admina w pracy/uczelni/cokolwiek nie mogły by korzystać bez problemów z większości stron www. Gdyż komunikacja by nie nastąpiła.
A tak w większości przypadków, mamy serwer HTTP, który po otrzymaniu przychodzącego połączenia na domyslny port 80. Oczekuje na polecenia zakończone "pustą liniją", a konkretnie znakiem końca linii. Na przykład CRLF. Posłużę się tutaj komponentem w znanym mi języku jakim jest obiektowy Pascal. Komponent Simple TCP to świetny twór, bazujący na WinAPI i czystych socketach. Można sobie przeanalizować jego źródła, jeśli ktoś woli. Prosty przykład, który pokazuje jak odwiedzić stronę www.google.pl i otrzymać odpowiedź w postaci tekstowej, bez obsłużenia dodatkowych nagłówków, czy też kodów błedu, przekierowań i tak dalej. Kod na stronie : http://piechnat.pl/index.php/files/highlight/tools/simpletcp/Client.dpr jak widać wysyłamy żądanie otrzymania dokumentu w głownym katalogu serwera, podajemy wersję protokołu, host serwera i wspomniane znaki kóńca lini w formacie "Windowsowym".
Sorry, może ktoś inny powinien się więcej wypowiedzieć. Ale na temat protokołu HTTP napisano na sieci tyle, że warto pogooglować i po prostu poczytać. Nie ma co dzielić włosa na czworo, czy wymyslać koła na nowo. Wszystko zostało już nie raz opisane dosyć dokładnie. A ja jako nieadmin i nie żaden expert z dziedziny portokołów, próbując coś uzmysławiać na temat tego protokołu. Czuję się trochę tak, jakbym musiał komuś trzeźwemu i dorosłemu wytłumaczyć dlaczego akurat 2+2=4. Można próbować, ale szkoda na to czasu i siły. Trzeba raczej zaakceptować wedle mnie w tym przypadku istniejący porządek Świata i tyle :/
EDIT: o @Shalom to dobrze ujął. Fakt, chodzi o te porty efemeryczne. One zawsze są otwierane i tutaj nie ma wiele do rzeczy fizyczny dostęp do komputera ze Świata. Trochę namieszałem. Sorry. A te porty widać na Windows po poleceniu netstat /a, jeśli kogoś interesują też inne szczegóły może je wyczytać ze sniffera opartego choćby o WinPCap, na przykład WireShark.
2
@olesio to są te same porty ALE po nawiązaniu komunikacji NAT/PAT przestaje być problemem. Ale musi nastąpić połączenie. Dlatego też klient za NATem musi wysłać żądanie do serwera który jest widoczny w sieci. Serwer przy odpowiadniu nie musi juz "widzieć" tego komputera. Ta widoczność jest istotna tylko i wyłącznie w celu nawiązania komunikacji.