[HTTP&네트워크] 인터넷 네트워크와 URI

[HTTP&네트워크] 인터넷 네트워크와 URI

인프런 - 김영한님의 HTTP 웹 기본 지식 강의를 들으면서 정리한 내용 입니다.

[인터넷 통신]

통신이란 클라이언트 가 서버 에게 무엇인가를 요청을 하게 되고, 서버가 그 요청에 해당하는 응답을 다시 클라이언트에게 주는 것을 말한다.

인터넷은 클라이언트와 서버간의 통신을 할 수 있도록 이어주는 수많은 노드들을 인터넷 이라고 일컫으며, 우리는 인터넷을 통해서 요청과 응답을 수행하며 통신을 할 수 있다.

인터넷 통신을 쉽게 말해, 택배를 부치는 과정과 비슷하다고 할 수 있다.

보내는 쪽(클라이언트)에서 목적지(서버)로 물건(데이터)을 박스(패킷)으로 포장해서 보낸다.

박스(패킷)은 옥뮤다 등 HUB(노드)들을 거치면서 목적지 까지 운반된다.

이러한 과정을 클라이언트 와 서버 측이 왔다갔다 이루어지는 것이 인터넷 통신이다.

[프로토콜]

프로토콜은 공통으로 지키는 규범, 약속 이라는 의미를 가진다.

인터넷 프로토콜이란, 인터넷 공간에서 원활한 통신을 위해 정해진 규범을 말하는데, 인터넷 프로토콜을 지키면서 통신을 하기 때문에, 통신이 원활하게 이루어 질 수 있는 것이다. (마치 우리가 한국어를 사용할 때 각 단어 용법의 쓰임을 정해서 의사소통을 하기 때문에 혼선 없이 이루어지듯이)

인터넷 프로토콜은 4개의 계층으로 분리해서 이루어지는데

1. 애플리케이션 계층( HTTP, FTP 등등)

2. 전송 계층 (TCP, UDP)

3. 인터넷 계층 (IP)

4. 네트워크 인터페이스 계층(물리적인 네트워크 연결)

데이터를 전송할 때는, 1 -> 2 -> 3-> 4 순서를 거치면서 데이터를 전송을 하게 된다.

반대로, 데이터를 수신할 때는, 4 -> 3 -> 2-> 1 순서를 통해 데이터를 받게 된다.

[애플리케이션 계층]

애플리케이션 계층은 흔히 웹브라우저에서 하는 일들을 생각하면 된다.

예를 들어, 우리가 " https://www.google.com/search?q=hello&hl;=ko " 주소를 요청한다고 생각해보자.

위에서 택배를 보내는 비유에서 처럼 여기서 [물건]에 해당하는 것이 https://www.google.com/search?q=hello&hl;=ko라는 HTTP 메시지가 된다.

이제 이 물건을 보내기 위해 포장을 하러 가기 위해 TCP 계층으로 전달해야 한다. 이때 흔히 SOCKET 라이브러리를 사용해서 TCP 계층으로 보내게 된다.

[IP(인터넷 프로토콜)]

IP 주소 라는 말은 익히 들어 왔듯이, 내 집 주소와, 보내는 사람의 주소와 같은 역할을 한다고 보면 된다.

IP 계층에서는 출발지인 클라이언트 IP 주소와 보내는 사람 주소인 서버 IP 주소를 적어서 보낸다.

사실 택배를 보내는데 있어, 내 집 주소와 보내는 사람 주소만 있으면 되지 않을까? 라고 할 수 있다. 사실 가능 할 수도 있다.

그러나 IP 프로토콜만 사용함에 있어 한계점이 있다.

1. 비연결성의 문제가 있다. 사실 택배는 문앞에 두고 가면 그만이지만, 인터넷 통신에서는 불가능하다. 즉, 받는 서버측에서 종료되어 있는 상태라면, 서버에서는 받지도 못했는데, 클라이언트는 그냥 데이터를 보낼 뿐이다.

2. 비신뢰성의 문제가 있다. 데이터를 보내는 도중 패킷이 소실되어 버리거나 패킷이 순서대로 오지 않을 수 있다.

다시말해, 택배가 분실되거나, 택배를 보낸 순서가 뒤죽박죽이 되어있을 수 있다.(컴퓨터는 순서대로 조립해서 데이터를 복원한다. 즉 https://www.google.com 이 https://comwww.google. 이 되어버린다면 읽지 못하는 것)

3. 프로그램 구분이 문제가 있다. 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면 어떤 애플리케이션 계층에 전달할 것인가의 문제가 있다.

그래서, TCP 라는 계층의 도입을 통해 IP 프로토콜의 한계점을 극복하였다.

[전송 계층]

전송계층에는 TCP(Transmission Control Protocol)와 UDP(User Data Protocol) 이 있다.

TCP의 특징은

1. 3 way handshake

2. 데이터 전달 보증

3. 순서 보장

이 있다.

1. 3 way handshake 는 데이터 전송 전에 해당 서버를 확인하는 것이다. SYN , SYN + ACK , ACK 라는 방식으로 데이터를 보내기 전에 확인 과정을 거치게 된다.

클라이언트는 SYN을 통해 서버에게 접속요청,

서버는 SYN + ACK 를 통해 접속 요청을 수락,

클라이언트는 ACK 와 함께 데이터를 전송 한다.

3 way handshake 가 필요한 이유는, 클라이언트 측에서 데이터를 보낼 때 사전 확인 작업이 없으면, 서버가 종료되어 있는 상태인지 알 수 없기 때문이다. 그래서 클라이언트는 데이터가 정상적으로 보내지는 지 모른 상태로 무작정 데이터를 보내게 되지만, 실패할 뿐이다. (택배를 보내기 전, 택배를 보낸다고 사전 고지를 해서 착오가 없도록 하는 것과 같다)

2. 전달 보증은 클라이언트가 데이터를 전송을 해서 서버가 데이터를 정상적으로 수신했다면, 클라이언트에게 데이터를 받았음을 알려주는 것이다. (택배를 받으면, 잘 받았다고 전화를 해주는게 인지상정?)

3. 순서 보장은 데이터의 이동 경로는 항상 보장되어 있지 않기 때문에, 데이터를 포장해온 패킷들이 반드시 보낸 순서대로 도착하지는 않는다. 그래서 여러 패킷들이 뒤죽박죽 오면 서버에서 정상적으로 데이터를 열어볼 수 없다. 그래서 기본적으로는 TCP에서 제공하는 패킷의 순서에 맞지 않으면, 해당 순번의 데이터부터 다시 요청을 해서 보낼 수 있도록 재요청을 한다.

예시를 적용해보면, 소켓 라이브러리를 통해 들어온 HTTP 요청 메시지를 (예시를 위해서) 잘게 쪼갠다. 해당 데이터를 TCP 라는 박스에 감싸고, TCP 박스에는 출발지와 목적지의 포트, 전송 제어, 순서, 검증 정보 등등 TCP 단에서 확인하는 정보를 추가한다.

** UDP(User Datagram Protocol)

UDP도 TCP 계층의 프로토콜인데, 매우 간단한 정보(포트 번호와 체크섬 - 자료의 무결성을 위한 중복 검사)만 추가하는 것을 말한다. 이 외의 정보는 애플리케이션에서 추가 작업을 수행한다.

여담으로 HTTP 3 버전에서는 UDP를 가지고 통신을 한다고 한다.

[PORT]

위에서 IP의 한계점 3개 중 2개는 해결 되었다. 마지막 동일 아이피의 여러 애플리케이션 구분이라는 문제는, 눈치 채다시피 포트를 통해서 해결 한다. Port, 즉 항구 라는 의미를 가지는 것 처럼, 동일한 아이피 주소를 가진다 하더라도 포트를 통해 구분한다.

애플리케이션에 각 포트를 할당함으로써, 동일한 아이피 내에서도 구분하는 역할을 한다.

0~1023 포트는 익히 알려진 번호로써, 해당 포트를 지정하여 사용하는 것을 피하는 것이 좋다.

(FTP - 20, 21 // TELNET - 23 // HTTP - 80 // HTTPS - 443 등..)

예시에 적용하면, 주소를 입력할 때 일반 주소와 상세 주소를 구분하는 것과 같이, IP주소는 일반적인 주소를 의미해서, 대략적인 건물까지 갈 수 있다. 반면 포트는 상세주소를 담당해서, 해당 목적지를 정확하게 찾아간다고 볼 수 있다.

( 예로, (그 유명한 반포자이) 주소가 [서초구 신반포로 230] + [xxxx동 xxxx호] 라고 하면, 서초구 신반포로 230 이 IP 주소, xxxx동 xxxx 호가 포트)

**네트워크 인터페이스 계층은 하드웨어와 연결하는 계층으로, 백엔드를 공부하는 현재 너무 딥하게 내려가지는 않을 거라 다루지 않겠습니다.

[DNS]

IP 주소를 토대로 데이터가 요청하고, 전송된다고 말을 했지만, 실생활에서 우리는 IP 주소를 가지고 요청하지 않는다. 왜냐하면 IP주소는 숫자로 이루어져 친숙하지 않을 뿐더러, 변경 가능한 값이기 때문이다.

예를 들어, 우리나라 주소는 지번 주소에서 도로명 주소로 변경되었는데, 반포동 20-43이 의미하는 것과 신반포로 230 이랑 동일한 의미지만 표기는 다르다.

이러한 이유로, 우리는 DNS(Domain Name System)을 이용한다. 우리가 흔히 보는 google.com, naver.com 같은 아이피 주소가 아닌 이름을 통해서 해당 아이피에 접근 가능하도록 만든 시스템이다.

google.com 이 200.200.200.3 에 할당되면, google.com 이라는 도메인 주소에 접근을 하면, DNS 서버에서 할당된 IP주소를 반환해서, 해당 IP주소를 활용해서 접속하는 것이다.

( 마치, 프로그래밍을 하다보면 우리가 Enum 타입을 사용하는 것과 마찬가지다. 쉽게 의미를 파악할 수 있으며, 해당 값이 가지는 고유 값에 접근이 가능 할 수 있도록)

[URI(Uniform Resource Identifier)]

통합 자원 식별자. 인터넷 상의 자원을 식별할 수 있는 유일한 주소이다. 하위 개념으로는 URL(Locator)과 URN(Name)이 있다.

URL은 위의 예제에 있듯이 흔히 DNS 로 표현되어있는 https://www.google.com/search?q=hello&hl;=ko 같이 표기된다.

URN의 경우 리소스에 이름을 부여해서 찾는 것이다.

일상에서 사용되는 것은 URL이 대부분이므로, URI 와 URL은 동격의 의미로써 사용됨을 가정으로 한다.

마치 도서관에서 책을 찾는 것을 생각하면, 분류-X번대-Y번째 책장 등 위치를 찾아가면 해당 책을 찾을 수 있다. 이런 방식이 위치를 기반으로 식별해서 찾아가는 URL 방식이다.

반면, 책 뒷편 바코드에는 isbn 처럼 도서관에서 고유번호로 책을 구분할 것이다. 이런 방식이 URN 방식.

그래서 URL 방식은 새로운 책이 들어오면서, 해당 책의 위치가 바뀔 수 있다. 반면 책의 고유번호를 부여해서 식별하는 방법은 바뀌지 않고 해당 고유번호를 쭉 사용하게 된다.

URL의 형태는 기본적으로 다음과 같다.

scheme://[userinfo@] host [:port][/path][?query][#fragment] 위의 예제인

https://www.google.com/search?q=hello&hl;=ko 와 비교해서 보자.

scheme -> https

userinfo -> 미사용

host -> www.google.com

port -> 443(생략. default)

/search -> path

?query -> q=hello&hl;=ko

fragment -> 미사용

scheme : 주로 프로토콜을 사용한다. 즉 이 요청이 어떤 프로토콜 요청인지 알려주는 정보이다.

여기서는 https 를 사용함으로써, 443 포트 번호가 default로 설정된다. http는 80포트

userinfo : URL에 사용자 정보를 포함해서 인증을 하지만 거의 사용하지 않는다.

host : 이 요청을 수행하는 주체를 적는다. 위에서 언급한 DNS를 주로 사용하지만 IP 주소를 직접 적는 것도 가능하다.

port : 접속 포트를 명시한다. 생략시 scheme에서 설정되는 default 포트를 사용한다.

/search : 리소스의 경로를 의미한다. 계층적 구조로 표현된다.

?query: key = value 형태로 '?' 를 사용함으로써 쿼리의 시작을 구분한다. & 로 쿼리를 계속해서 이어나갈 수 있다.

fragmet : html 내부에서 사용되는 것으로 예를 들어 글을 쭉 읽어 내려가다 중간의 북마크를 통해 스크롤을 이동하는 경우처럼 서버에 전송하는 내용은 아니다.

from http://devcabinet.tistory.com/31 by ccl(A) rewrite - 2021-11-27 22:27:09