1장 웹과 네트워크의 기본에 대해 알아보자
1.1 웹은 HTTP로 나타낸다
웹 브라우저에 www.naver.com을 입력하면 우리는 네이버라는 웹 페이지를 볼 수 있다.
입력란에 지정된 URL을 통해 네이버 서버로부터 index.html이라는 리소스를 받게 되기 때문이다.
요청을 하는 웹 브라우저등을 클라이언트라고 하고 요청을 받아서 응답하는 쪽을 서버라고 한다.
클라이언트와 서버간의 통신은 HTTP라는 프로토콜을 기반으로 이루어진다.
1.2 HTTP는 이렇게 태어났고 성장했다.
1.2.1 웹은 지식 공유를 위해 고안되었다
1989년 3월에 HTTP는 탄생했다.
CERN(유럽 입자 물리학 연구소)의 팀 버너스 리는 멀리 떨어져 있는 동료 연구자와 지식을 공용하게 할 수 있는 시스템을 고안하였는데 이것이 WWW의 기본 개념이 되었다.
WWW를 구성하는 기술로는 HTML, HTTP, URL등 세 가지가 제안되었다.
WWW는 지금으로 말하자면 웹 브라우저, 그 당시에는 하이퍼텍스트를 열람할 수 있는 클라이언트 애플리케이션의 명칭이었다.
1.2.2 웹이 성장한 시대
1990년 11월 CERN에서 세계 최초의 웹 서버와 웹 브라우저가 개발되었다.
3년 뒤인 1993년에는 대한민국 최초의 홈페이지가 개발되었다.
이후에 1994년 12월에 넷스케이프에서 넷스케이프 내비게이터 1.0 출시, 1995년에는 마이크로소프트에서 인터넷 익스플로러 1.0과 2.0 출시되며 1차 브라우저 전쟁이 시작되었다.
두 브라우저는 독자적으로 HTML을 확장해나갔기 때문에 웹 표준을 무시하였는데 넷스케이프가 쇠퇴하게 되면서 일단 IE의 승리가 되었다. 이후에 2004년에 모질라 파이어폭스가 출시되면서 2차 브라우저 전쟁이 시작, 이후 크롬, 오페라, 사파리등의 브라우저도 생겨났다.
1.2.3 진보 안하는 HTTP
- HTTP/0.9
- HTTP는 1990년대에 등장하였는데 정식 사양서가 아니었다.
- HTTP 1.0 이전이라는 의미에서 0.9로 불린다.
- HTTP/1.0
- HTTP가 정식 사양으로 공개된 것은 1996년 5월, HTTP/1.0으로 RFC 1945 발행
- 초기의 사양이지만 아직 많은 서버상에서 현역으로 가동되고 있는 프로토콜 사양이다.
- HTTP/1.1
- 1997년 1월에 공개된 HTTP/1.1 버전, 현재 가장 많이 사용된다.
- RFC2616이 최신 버전이다.
HTTP는 등장한 당시에는 주로 텍스트를 전송하기 위한 프로토콜이었지만, 기능이 계속해서 추가되었고 지금은 웹이라는 틀을 넘어서 다양하게 사용되는 프로토콜이다.
1.3 네트워크의 기본은 TCP/IP
인터넷을 포함하여 일반적으로 사용하고 있는 네트워크는 TCP/IP 라는 프로토콜에서 움직이고 있고 HTTP는 그 중 하나다.
1.3.1 TCP/IP는 프로토콜의 집합
컴퓨터와 네트워크 기기가 상호간에 통신하기 위해서는 서로 같은 방법으로 통신하지 않으면 안된다.
어떻게 상대를 찾고, 어떻게 상대에게 이야기를 시작하고, 어떤 언어로 이야기를 하며, 어떻게 이야기를 종료하는 등 규칙이 필요한데 이러한 규칙을 프로토콜이라고 한다.
프로토콜에는 케이블 규격이랑 IP 주소 지정 방법, 떨어진 상대를 찾기 위한 방법과 그 곳에 도달하는 순서, 그리고 웹을 표시하기 위한 순서등이 있다.
이렇게 인터넷과 관련된 프로토콜을 모은 것이 TCP/IP라고 한다.
1.3.2 계층으로 관리하는 TCP/IP
TCP/IP에서는 계층(Layer) 개념이 중요하다.
‘애플리케이션 계층’, ‘트랜스포트 계층’, ‘네트워크 계층’, ‘링크 계층’ 이렇게 4계층으로 나누어져 있다.
계층화 된 이유는 관심사의 분리와 비슷하다. 변경 사항이 있으면 해당 계층만 변경하면 되고 자신의 역할만 고려하면 된다.
애플리케이션 계층
유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정한다.
FTP, DNS, HTTP등이 이 계층에 포함된다.
트랜스포트 계층
애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공한다.
트랜스포트 계층에서는 서로 다른 성향을 가진 TCP(Transmission Control Protocol)와 UDP(User Data Protocol) 프로토콜이 있다.
네트워크 계층(혹은 인터넷 계층)
네트워크 상에서 패킷의 이동을 다룬다. (패킷이란 전송하는 데이터의 최소 단위)
이 계층에서는 어떠한 경로를 거쳐 상대의 컴퓨터까지 패킷을 보낼지를 결정하기도 한다.
인터넷의 경우에는 상대 컴퓨터에 도달하는 동안 여러 대의 컴퓨터랑 네트워크 기기를 거치게 되는데 여러 가지 선택지 중에서 하나의 길을 결정하는 것이 네트워크 계층의 역할이다.
링크 계층(혹은 데이터 링크 계층, 네트워크 인터페이스 계층)
네트워크에 접속하는 하드웨어적인 면을 다룬다.
운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버랑 NIC를 포함한다. 케이블과 같은 물리적으로 보이는 부분도 포함한다.
하드웨어적 측면은 모두 링크 계층의 역할이다.
1.3.3 TCP/IP 통신의 흐름
TCP/IP로 통신을 할 때 계층은 순서대로 거쳐 상대와 통신을 한다.
송신하는 측은 애플리케이션 계층부터 내려가고 수신하는 측은 애플리케이션 계층으로 올라간다.
HTTP를 예로 들면
- 클라이언트의 애플리케이션 계층에서 HTTP 리퀘스트를 지시
- 트랜스포트 계층(TCP)에서는 애플리케이션 계층에서 받은 데이터를 통신하기 쉽게 조각내어 안내 번호와 포트 번호를 붙여 네트워크 계층에 전달
- 네트워크 계층(IP)에서는 수신지 MAC 주소를 추가해서 링크 계층에 전달, 네트워크를 통해 송신할 준비완료
- 수신측 서버는 링크 계층에서 데이터를 받아들여 순서대로 위의 계층에 전달하여 애플리케이션 계층까지 도달한다. 애플리케이션 계층에 도달하면 클라이언트가 발신했던 HTTP 리퀘스트 내용을 수신할 수 있다.
각 계층을 거칠 때 헤더라고 불리는 해당 계층마다 해당 계층에서 필요한 정보를 추가한다. 반대로 수신측에서는 각 계층을 거칠 때마다 반드시 해당 계층마다 사용한 헤더를 삭제한다. 정보를 감싸는 것을 캡슐화라고 한다.
1.4 HTTP와 관계가 깊은 프로토콜은 IP/TCP/DNS
1.4.1 배송을 담당하는 IP
IP(Internet Protocol)는 계층으로 말하자면 네트워크 계층이다.
IP의 역할은 개개의 패킷을 상대방에게 전달하는 것이다.
상대방에게 전달하기 위해서는 IP 주소와 MAC 주소가 중요하다.
IP 주소는 각 노드에 부여된 주소를 가리키고 MAC 주소는 각 네트워크 카드에 할당된 고유의 주소다.
IP 주소는 MAC 주소와 결부되며 IP 주소는 변경이 가능하지만 기본적으로 MAC 주소는 변경할 수 없다.
통신은 ARP를 이용하여 MAC 주소에서 한다
IP 통신은 MAC 주소에 의존해서 통신을 한다.
인터넷에서 통신은 여러 대의 컴퓨터와 네트워크 기기를 중계해서 상대방에게 도착한다. 이 과정에서 다음으로 중계할 곳의 MAC 주소를 사용하여 목적지를 찾아가게 된다. 이때 ARP(Address Resolution Protocol)라는 프로토콜이 사용된다.
ARP는 주소를 해결하기 위한 프로토콜 중 하나인데, 수신지의 IP 주소를 바탕으로 MAC 주소를 조사할 수 있다.
그 누구도 인터넷 전체를 파악하고 있지는 않다
컴퓨터와 라우터 등의 네트워크 기기는 목적지에 도착하기까지 대략적인 목적지만을 알고 있다.
이 시스템을 라우팅이라고 부르는데 최종 목적지에 도착하기 위해 본인의 지역에서 어디로 보내면 되는지만 알고 있고 전체를 상세하게 파악하고 있지는 못한다.
1.4.2 신뢰성을 담당하는 TCP
TCP(Transfer Control Protocol)은 계층으로 말하자면 트랜스포트 층에 해당하고, 신뢰성 있는 바이트 스트림 서비스를 제공한다. 바이트 스트림 서비스란 용량이 큰 데이터를 보내기 쉽게 TCP 세그먼트라고 불리는 단위 패킷으로 작게 분해하여 관리하는 것을 말하고 신뢰성 있는 서비스는 상대방에게 보내는 서비스를 의미한다.
TCP는 대용량의 데이터를 보내기 쉽게 작게 분해하고 정확하게 도착했는지 확인하는 역할을 한다.
상대에게 데이터를 확실하게 보내는 것이 일이다
확실하게 데이터를 보내기 위해 TCP는 three way handshaking이라는 방법을 사용한다.
패킷을 보내고 나서 바로 끝내는 것이 아니라, 보내졌는지 여부를 상대에게 확인하러 간다. 이때 ‘SYN’과 ‘ACK’라는 TCP 플래그를 사용한다.
송신측에서는 최초에 ‘SYN’ 플래그로 상대에게 접속함과 동시에 패킷을 보내고, 수신측에서는 ‘SYN/ACK’ 플래그로 송신측에 접속함과 동시에 패킷을 수신한 사실을 전한다. 마지막으로 송신측이 ‘ACK’ 플래그를 보내 패킷 교환이 완료 되었음을 전한다.
이 과정에서 통신이 도중에 끊어지면 TCP는 그와 동시에 같은 수순으로 패킷을 재전송한다.
1.5 이름 해결을 담당하는 DNS
DNS(Domain Name System)은 HTTP와 같이 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공한다. 컴퓨터는 IP 주소와는 별도로 호스트 이름과 도메인 이름을 붙일 수 있다.
주로 사용자는 IP 주소 대신 읽기 쉽고 외우기 쉬운 이름을 이용하여 상대의 컴퓨터를 지정하는데, DNS는 도메인명에서 IP 주소를 조사하거나 반대로 IP 주소로부터 도메인명을 조사하는 서비스를 제공한다.
1.6 각각과 HTTP와의 관계
IP, TCP, DNS가 HTTP를 이용해 통신을 할 때
- 먼저 DNS에게 www.naver.com의 주소를 요청한다.
- HTTP 메시지를 작성한다.
- 통신하기 쉽도록 HTTP 메시지를 패킷으로 분해하고 일련번호를 부여하고 보낸다.
- 상대가 어디에 있는지 찾아 중계하면서 배송한다.
- 상대방으로부터 패킷을 수신하고 일련번호에 따라 조립한다.
- HTTP 메시지를 처리한다.
리퀘스트 처리 결과도 마찬가지로 TCP/IP xㅗㅇ신 순서대로 클라이언트에 반환된다.
1.7 URI와 URL
웹 브라우저 등으로 웹 페이지를 표시하기 위해 입력하는 주소가 URL이다.
1.7.1 URI는 리소스 식별자
URI는 Uniform Resource Identifiers의 약자다.
Uniform
통일된 서식을 결정하는 것으로, 여러 가지 종류의 리소스 지정 방법을 같은 맥락에서 구별없이 취급하게 한다. 또한, 새로운 스키마(http:와 ftp 등) 도입을 용이하게 한다.
Resource
리소스는 식별 가능한 모든 것으로 정의되어 있다.
도큐먼트 파일뿐만 아니라 이미지와 서비스 등 다른 것과 구별할 수 있는 것은 모두 리소스다.
Identifier
식별 가능한 것을 참조하는 오브젝트이며 식별자로 불린다.
결국 URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자다. 스키마는 리소스를 얻기 위한 수단에 이름을 붙이는 방법이다.
URI는 리소스를 식별하기 위해 문자열 전반을 나타내는데 비해 URL은 리소스의 장소를 나타낸다.
URL은 URI의 서브셋이다.
1.7.2 URL 포맷
절대 URL과 상대 URL이 있다.
http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
- http:, https:는 프로토콜이다.
- 서버로부터 리소스를 취득하려면 자격정보(크리덴셜)이 필요한데 (user:pass) 이것은 옵션이다.
- 서버 주소는 www.example.jp와 같이 DNS 이름이나 IPv4, IPv6 주소를 지정한다.
- 서버 포트는 접속 대상이 되는 네트워크 포트 번호다.
- /dir/index.html은 특정 리소스를 식별하기 위한 파일 패스(file path)다.
- 리소스에 임의의 파라미터를 넘겨주기 위해 ?uid=1과 같은 쿼리 문자열을 사용한다. 이것은 옵션이다.
- #ch1과 같이 취득한 리소스에서 서브 리소스를 가리키기 위하여 프래그멘트 식별자가 사용된다. 이것은 옵션이다.
'TIL > 개발' 카테고리의 다른 글
Partial Prerendering(PPR)은 어떤 렌더링 방식일까? (0) | 2023.12.10 |
---|---|
그림으로 배우는 Http & Network Basic - 2장 (0) | 2023.12.06 |
[리팩토링 2판 스터디] 2회차 정리 (0) | 2023.12.05 |
[리팩토링 2판 스터디] 1회차 정리 (0) | 2023.11.18 |
요즘 개발자 베타리딩 - 2주차 (0) | 2023.11.09 |