웹 브라우저
URL(Uniform Resource Locator)은 http:// 로 시작하는 것이라고 알고있지만, 그 밖에 file: , mailto: , 로 시작하는 것 등 여러가지가 있습니다.브라우저는 웹 서버에 액세스하는 클라이언트로 사용하는 경우가 많지만, 파일을 다운로드/업로드하는 FTP의 클라이언트 기능이나 메일의 클라이언트 기능도 가지고 있습니다. 브라우저는 몇 개의 클라이언트 기능을 겸비한 복합적인 클라이언트 소프트웨어라고 할 수 있습니다. 이러한 기능 중의 어느 것을 사용하여 데이터에 액세스하면 좋을 것인지 판단하는 재료가 필요한데, 그 재료가 URL 입니다.
FTP(File Transfer Protocol) : 파일을 업로드하거나 다운로드할 때 사용하는 프로토콜
1. HTTP 리퀘스트 메시지를 작성한다
모든 URL에는 하나의 공통점이 있는데, URL의 맨 앞에 있는 문자열, 즉 http:, ftp:, file:, mailto:라는 부분에 액세스하는 방법을 나타낸다는 점입니다. 액세스 대상이 웹 서버라면 HTTP라는 프로토콜을 사용하여 액세스하고, FTP 서버라면 FTP라는 프로토콜을 사용합니다. 즉, 액세스할 때의 '프로토콜 종류'가 쓰여있습니다.
1-1. 브라우저가 처음하는 일
브라우저가 처음 하는 일은 웹 서버에 보내는 리퀘스트의 메시지를 작성하기 위해 이 URL을 해독하는 것입니다.http://aurealstn.tistory.com/25 라는 URL을 봅시다.http:는 프로토콜, //는 나중에 이어지는 문자열이 서버의 이름임을 나타냄, aurealstn.tistory.com은 웹 서버 네임이죠. 그 다음 /25 부분이 데이터 출처의 경로명입니다.http://aurealstn.tistory.com/ 이러한 URL도 보셨을 겁니다. 원래는 / 뒤에 파일명을 적어줘야 하지만 이렇게 생각이 되어있을 경우에는 서버가 index.html 또는 default.html 이라는 파일에 액세스 합니다. com 뒤에 / 까지 생략을 해도 결과는 같습니다.
1-2. HTTP의 기본 개념
HTTP 프로토콜은 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 것.
먼저 클라이언트에서 서버를 향해 리퀘스트 즉, 요구 메시지를 보냅니다. 리퀘스트 메시지 안에는 '무엇을', '어떻게 해서' 하겠다는 내용이 있습니다.
'무엇을' 에 해당하는 것을 URI(Unifrom Resource Identifier)라고 하는데, 보통 페이지 데이터를 저장한 파일의 이름이나 CGI 프로그램의 파일명을 URI로 씁니다.
CGI 프로그램 : 웹 서버 소프트웨어에서 프로그램을 호출할 때의 규칙을 정한 것이 CGI이며, CGI의 규칙에 맞게 움직이는 프로그램을 말합니다.
예를 들어, /dir1/file1.html 이나 /dir/program.cgi 같은 식입니다. 뿐만 아니라 URI는 http:로 시작하는 URL을 그대로 쓸 수 있습니다. 즉 여기에는 다양한 액세스 대상을 쓸 수 있으며, 이러한 액세스 대상을 통칭하는 말이 URI입니다.
다음으로 '어떻게 해서'에 해당하는 것이 메소드 입니다. 이 메소드에 의해 웹 서버에 어떤 동작을 하고 싶은지를 전달합니다.
웹 서버에 리퀘스트 메시지가 도착하면 그에 대한 응답 메시지를 보내주는데 응답 메시지의 맨 앞 부분에는 실행 결과가 정상 종료되었는지 또는 이상이 발생했는지를(ex. 404 Not Found) 나타내는 스테이터스 코드가 있습니다. 그 후 헤더 파일과 페이지의 데이터가 이어지고, 이 응답 메시지를 클라이언트에 반송합니다. 이것이 클라이언트에 도착하여 브라우저가 메시지의 안에서 데이터를 추출하여 화면에 표시하면서 HTTP의 동작은 끝이납니다.
"웹은 서버와 클라이언트 둘 간의 메시지 교환으로 해석, 동작한다" 로 해석될 수 있겠네요.
1-3. HTTP의 대표적인 메소드
- GET : URI로 지정한 정보를 도출합니다.
- POST : 클라이언트에서 서버로 데이터를 송신합니다. 폼에 입력한 데이터를 송신.
- PUT : URI로 지정한 서버의 파일을 변경, 수정
- DELETE : URI로 지정한 서버의 파일을 삭제
GET 은 예를 들어 URI에 /dir/file.html 이라는 파일의 데이터를 읽으라는 의미입니다.
즉 파일을 열고 내용의 데이터를 추출 -> 추출한 데이터를 응답 메시지에 포함해서 클라이언트에게 전송 -> 클라이언트 측은 브라우저가 이것을 받아 화면에 표시
POST 폼에 데이터를 사용해서 웹 서버에 송신하는 경우에 사용합니다.
우리가 웹 사이트에서 물건을 살 때 주소를 입력하잖아요? 그리고 설문 조사나 회원 가입할때 입력 필드가 있는데 이러한 것이 폼입니다.
POST 메소드를 사용한 경우 URI에는 웹 서버 기계에서 동작하는 애플리케이션 프로그램의 파일명을 쓰는데, index.cgi나 index.php가 대표적인 파일명입니다.
사용자가 필드에 입력한 메시지가 서버에 도착하면 웹 서버 소프트웨어는 URI에 지정된 애플리케이션 프로그램에게 리퀘스트 메시지의 안에 쓰여있는 데이터를 건네줍니다. 그리고 이 프로그램이 출력하는 데이터를 받아서 응답 메시지에 포함시킨 후 클라이언트에게 반송합니다.
애플리케이션 프로그램 : 쇼핑의 주문 데이터를 처리하거나 설문 조사의 데이터를 처리하는 프로그램
PUT이나 DELETE를 사용하면 클라이언트에서 웹 서버의 파일을 바꿔쓰거나 삭제하는 것도 가능하지만, 보안상의 이유로 잘 사용하진 않습니다.
리퀘스트 메시지에 쓰는 URL은 하나뿐으로, 복수의 파일을 읽을 때는 웹 서버에 별도의 리퀘스트 메시지를 보냅니다.
2. 웹 서버의 IP주소를 DNS서버에 조회한다
HTTP의 메시지를 만들면 다음에는 기것을 OS에 의뢰하여 액세스 대상의 웹 서버에게 송신합니다. 브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 메시지를 네트워크에 송출하는 기능은 없으므로 OS에 의뢰하여 송신하는 것입니다. 이 때 안에 쓰여있는 서버의 도메인명에서 IP주소를 조사해야 합니다.
도메인명 :
www.youtube.com와 같이 마침표(.)로 구분하여 표현하는 이름
2-1. TCP/IP
TCP/IP는 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어진다고 생각할 수 있습니다. 여기에서 말하는 서브넷이란, 허브에 몇 대의 PC가 접속된 것이라고 생각해도 좋습니다. 이것을 한 개의 단위로 생각하여 '서브넷' 이라고 부르는데, 라우터에서 연결하면 네트워크 전체가 완성됩니다.
라우터 : 패킷을 중계하는 장치의 일종
허브 : 패킷을 중계하는 장치의 일종이며, 리피터 허브와 스위칭 허브의 두 가지 유형이 있습니다.
'OO동 OO번지' 라는 형태로 네트워크의 주소를 할당한다고 가정합시다. 동에 해당하는 번호를 서브넷에 할당하고, 번지에 해당하는 번호를 컴퓨터에 할당한 것이 네트워크의 주소입니다.
이 동에 해당하는 번호를 네트워크 번호라 하고, 번지에 해당하는 번호를 호스트 번호라 하며, 이 두 주소를 합쳐서 IP 주소라고 합니다.
집 주소가 다른 집 주소와 같을 수 없듯이 IP 주소 역시 같을 수 없습니다.
액세스 대상의 서버까지 메시지를 운반할 때는 이 IP 주소에 따라 액세스 대상이 어디에 있는지 판단하고 운반합니다. 송신측이 메시지를 보내면 서브넷 안에 있는 허브가 운반하고, 송신측에서 가장 가까운 라우터까지 도착합니다. 그리고 라우터가 메시지를 보낸 상대를 확인하여 다음 라우터를 판단하고, 거기에 보내도록 지시하여 송신 동작을 실행한 후 다시 서브넷의 허브가 라우터까지 메시지를 보냅니다. 이런 동작을 반복하면 최종적으로 상대의 데이터가 도착한다는 원리인데, 이것이 TCP/IP와 IP 주소의 기본적인 개념입니다.
실제 IP 주소는 32비트의 디지털 데이터로, 8비트씩 점으로 구분하여 10진수로 표기합니다.
하지만 이것만으로는 어느 부분이 네트워크 번호 또는 호스트 번호인지 알 수 없습니다. 즉, IP 주소는 두 가지를 합쳐서 32비트로 한다는 것만 결정되어 있을뿐 내역을 결정되어 있지 않습니다.
"네트워크를 구축할 때 사용자가 직접 내역을 결정할 수 있습니다."
그러므로 이 내역을 나타내는 정보를 필요에 따라 IP 주소에 붙이는데, 이 정보를 넷마스크 라고 합니다.
IP 주소의 호스트 번호
- 모두 0 : 서브넷 자체를 나타냅니다.
- 모두 1 : 서브넷에 있는 기기 전체에 패킷을 보내는 '브로드캐스트' 를 나타냅니다.
2-2. 도메인명과 DNS
"URL에 서버명 대신에 IP 주소를 치면 되지 않느냐" 라고 할 수 있지만, IP 주소는 외우기가 쉽지 않죠. 우리가 전화번호를 외우기 보다면 그 번호를 저장하고 네임을 따로 지어줍니다.
이처럼 외우기 쉽게 도메인명을 지어주죠. 그리고 도메인명을 알면 IP 주소를 알 수 있다거나 IP 주소를 알면 이름을 알 수 있다는 원리를 사용하여 양쪽의 차이를 해소하면 모두 좋아지는데, 그 원리가 DNS 입니다. DNS(Domain Name System)는 서버명과 IP 주소를 대응시키기 위해 DNS를 가장 많이 사용하지만, 메일 주소와 메일 서버를 대응시키는 것 등 다양한 정보를 이름에 대응해서 등록할 수 있습니다.
DNS 서버는 웹 서버의 이름에서 IP 주소를 조사하기 위해 사용하는 서버입니다.
3. 전세계의 DNS 서버가 연대한다
DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회의 내용에 응답하는 형태로 정보를 회답하는 일입니다. DNS 서버는 서버에 등록된 도메인명과 IP 주소의 대응표를 조사하여 IP 주소를 회답합니다. DNS 서버와 도메인은 항상 1대1이 아니라 한대의 DNS 서버에 복수의 도메인 정보를 등록할 수 있습니다.
또한 DNS 서버는 한번 조사한 이름을 캐시에 기록할 수 있는데, 조회한 이름에 해당하는 정보가 캐시에 있으면 그 정보를 회답하기 때문입니다.
조회한 이름이 도메인에 등록되어 있지 않은 경우에는 이름이 존재하지 않는다는 회답이 돌아오지만, 그것을 캐시에 보존하여 빠르게 회답할 수도 있습니다.
4. 프로토콜 스택에 메시지 송신을 의뢰한다
IP 주소를 조사했으면 IP 주소의 상대, 여기에서는 액세스 대상 웹 서버에 메시지를 송신하도록 OS의 내부에 있는 프로토콜 스택에 의뢰합니다.
프로토콜 스택 : OS 내부에 내장된 네트워크 제어용 소프트웨어, '프로토콜 드라이버', 'TCP/IP 소프트웨어' 등으로도 부릅니다.
데이터를 송, 수신할 때 두 사이를 파이프로 연결하는 동작이 필요합니다. 이 파이프의 양끝에 있는 데이터의 출입구를 소켓이라고 합니다. 그리고 디스크립터는 소켓을 식별하기 위해 사용하는 것으로, 예를 들어보면 브라우저에서 2개의 창을 열어 2개의 웹 서버에 동시에 액세스하는 장면에서 2개의 소켓을 만들어야 합니다. 이 경우 하나하나의 소켓을 식별해야 하는데, 이것이 디스크립터입니다.
IP 주소는 네트워크에 존재하는 각 컴퓨터를 식별하기 위해 각각에 서로 다른 값을 할당한 것입니다. 즉 IP 주소로 지정할 수 있는 것은 네트워크의 어느 컴퓨터인가 하는 것까지입니다. 접속 동작은 상대측의 소켓에 대해 이루어지므로 소켓을 지정해야 하는데, IP 주소로는 소켓까지 지정할 수 없습니다. 그래서 필요한 것이 포트 번호입니다.
- 디스크립터는 컴퓨터 한 대의 내부에서 소켓을 식별하기 위해 사용
- 포트 번호는 접속 상대측에서 소켓을 식별하기 위해 사용
connect 를 호출하면 프로토콜 스택이 접속 동작을 실행합니다. 그리고 상대와 연결되면 프로토콜 스택은 연결된 상대의 IP 주소나 포트 번호 등의 정보를 소켓에 기록합니다. 이로써 데이터 송, 수신이 가능한 상태가 됩니다.
- 디스크립터 : 애플리케이션이 소켓을 식별하는 것
- IP 주소와 포트 번호 : 클라이언트와 서버 간에 상대의 소켓을 식별하는 것
**HTTP 프로토콜은 HTML 문서나 영상 데이터를 하나하나 별도의 것으로 취급하여 1개의 데이터를 읽을 때마다 접속, 리퀘스트 메시지 송신, 응답 메시지 수신, 연결 끊기라는 동작을 반복합니다. 따라서 하나의 웹 페에지에 영상이 많이 포함되어 있으면 접속, 송수신, 연결 끊기 동작을 여러 번 반복하여 속도가 느려지죠.
TCP/IP 전기신호
네트워크 제어용 소프트웨어를 '프로토콜 스택' 이라고 하는데, 이 소프트웨어는 브라우저에서 받은 메시지를 패킷 속에 저장하고, 수신처 주소 등의 제어 정보를 덧붙입니다.
프로토콜 스택은 이 패킷을 LAN 어댑터(이더넷이나 무선 LAN으로 통신할 때 사용하는 하드웨어)에 넘깁니다. 그리고 LAN 어댑터가 이것을 전기신호로 변환하고 LAN의 케이블에 송출하는 과정을 통해 패킷이 네트워크 속으로 들어갑니다.
1. 소켓을 작성한다
애플리케이션 아래부분에는 Socket 라이브러리가 있으며, 그 안에는 리졸버가 내장되어 있습니다.
리졸버 : DNS 클라이언트에 해당하는 것
Socket 라이브러리 : OS에 포함되어 있는 네트워크의 기능을 애플리케이션에서 호출하기 위한 부품을 모아놓은 것
그 아래가 OS의 내부를 나타내며, 프로토콜 스택이 있습니다. 프로토콜 스택 윗부분에는 TCP라는 프로토콜 또는 UDP를 사용하여 데이터 송수신을 담당합니다. 이 둘이 애플리케이션에서 보낸 의뢰를 받아 송수신 동작을 실행합니다.
- 브라우저나 메일 등의 일반적인 애플리케이션이 데이터를 송수신할 경우 TCP
- DNS 서버에 대한 조회 등에서 짧은 제어용 데이터를 송수신할 경우 UDP
그 아래에는 IP 프로토콜을 사용하여 패킷 송수신 동작을 제어하는 부분이 있습니다. 인터넷에서 데이터를 운반할 때는 데이터를 작게 나누어 패킷이라는 형태로 운반하는데, 이 패킷을 통신 상대까지 운반하는 것이 IP의 주 역할입니다.
그리고 IP 안에는 ICMP와 ARP 라는 프로토콜을 다루는 부분이 포함되어 있습니다.ICMP는 패킷을 운반할 때 발생하는 오류를 통지하거나 제어용 메시지를 통지할 때, ARP는 IP 주소에 대응하는 이더넷의 MAC 주소를 조사할 때 사용합니다.
MAC 주소 : IEEE에서 표준화된 LAN 방식의 기기는 모두 같은 형식의 주소를 사용하고 이 주소를 MAC 주소라고 부릅니다.
IP 아래에 있는 LAN 드라이버는 LAN 어댑터의 하드웨어를 제어합니다. 그리고 그 아래에 있는 LAN 어댑터가 실제 송수신 동작, 즉 케이블에 대해 신호를 송수신하는 동작을 실행합니다.
소켓에는 통신 동작을 제어하기 위한 여러가지 제어정보가 기록되어 있습니다. 프로토콜 스택은 이것을 참조하여 다음에 무엇을 해야 하는지를 판단하는데, 이것이 소켓의 역할입니다.
프로토콜 스택은 소켓에 기록된 제어 정보를 참조하면서 움직입니다.
2. UDP 프로토콜을 이용한 송수신 동작
이더넷은 다수의 컴퓨터가 여러 상대와 자유롭게 적은 비용으로 통신하기 위해 고안된 통신 기술입니다.
DNS 서버에 대한 조회 등 제어용으로 실행하는 정보 교환은 한 개의 패킷으로 끝나는 경우가 많으므로 TCP가 아니라 UDP를 사용합니다. UDP에는 TCP와 같은 수신 확인이나 윈도우가 없어서 데이터 송수신 전에 제어 정보를 주고받을 필요가 없고, 접속이나 연결 끊기 단계가 없습니다. 애플리케이션에서 송신 데이터를 받으면 여기에 UDP 헤더를 부가하고 이것을 IP에 의뢰하여 송신하기만 합니다.
음성이나 영상의 데이터를 보낼 때도 UDP를 사용합니다. 음성이나 영상 데이터는 결정된 시간 안에 데이터를 보내야 하는데, TCP 같은 경우 수신 확인 응답에 의해 오류를 검출하여 다시 보내는 방법이라면 시간이 좀 걸립니다.
음성이라면 없어진 순간 '치직'하면서 소리가 끊길 뿐이고, 영상이라면 영상이 잠깐 멈출 뿐이므로 이처럼 다시 보낼 필요가 없거나 다시 보내도 쓸모가 없으면 단순히 UDP로 데이터를 보내는 쪽이 더 효율적일 것입니다.
여기까지 네트워크 기초 포스트 작성을 마치겠습니다.
이 책은 Tsutomu Tone 저자의 성공과 실패를 결정하는 1%의 네트워크 원리 라는 책이고, 이도희님의 번역과 이중호님의 감역을 맡은 책입니다. 이 책은 정말 웹의 원리부터 파고 들어서 아주 자세히 설명이 나왔습니다. 저는 아주 일부분만 정리하였습니다. 다시 자세히 읽어야봐야 될 것 같군요.ㅎㅎ
댓글