조승현

White Christmas: 영국 드라마 ‘블랙미러’에서 가장 좋아하는 에피소드의 소제목입니다.

2 minute read

클라이언트와 서버가 있을 때

클라이언트가 Hello를 보내면

서버에서 Hi라는 응답이 온다고 하자.

서로가 선으로 연결된 것도 아닌데

서로의 위치를 어떻게 알고 보낼 수 있을까?

클라이언트와 서버는 각각이 고유의 IP주소가 있다.

Hello 메시지를 보내는 사람 IP주소, 받는 사람 IP주소가 담긴 패킷에 담아

발송하면 클라이언트와 서버 사이에 있는 수많은 노드들(인공위성, 해저 케이블 등)을 왔다갔다 하며

서버의 IP주소와 일치하는 곳으로 Hello를 전달한다.

하지만 패킷(Packet)이라는 통신 단위로 IP(인터넷 프로토콜) 주소에 전달하는 방법은

  1. 상대방이 요청을 받을 수 있는 상태인지 여부를 알 수 없고

  2. 전송하던 패킷이 중간에 유실되거나 왜곡될 수 있으며

  3. 패킷을 쪼개서 전송하는 경우 도착 순서를 보장하지 않는다.

  4. 또한 IP 주소로만 메시지를 식별하면 다양한 애플리케이션에서 오는 응답들이 어느 애플리케이션에서 온 응답인지 어떻게 구별하느냐는 문제도 있다.

위 문제점들을 보완하기 위해

Hello라는 메시지를 보낼 때

TCP, PORT 등을 이용한 프로토콜 계층을 따라 전달된다.

  1. 애플리케이션 계층에서 프로그램이 Hello라는 메시지를 생성한다.

  2. SOCKET 라이브러리를 통해 os계층으로 전달한다.

  3. TCP 정보를 생성하여 메시지 데이터를 감싼다.

    TCP? -> Transmission Control Protocol

    패킷이 안전하게 도착할 수 있도록 제어하는 프로토콜.

    상대방이 연결을 받을 수 있는 상태인지 확인하기 위해

    TCP 3 way handshake를 사용한다.

    클라이언트와 서버 사이에 SYN, SYN+ACK, ACK 순서로 주고 받으면서

    서로가 연결된 상태임을 논리적으로 인지한 후(물리적으로 연결된 것은 아니라 한다)

    Hello 메시지를 TCP 세그먼트로 감싼다.

    TCP 세그먼트에는

    출발지 PORT, 목적지 PORT

    (어떤 애플리케이션 간의 연결인지 구분하기위해 사용하는 것이 PORT이다.

    IP주소는 아파트, PORT 값은 동/호수로 표현할 수 있다)

    , 전송 제어, 순서, 검증 정보 등이 포함되어 있다.

    요청이 잘 갔을 경우 잘 받았다는 응답을 받도록 함으로써

    데이터의 전달을 보증하고,

    TCP 세그먼트의 보내는 데이터의 순서를 적어서 보내므로

    순서가 틀리게 올 경우 다시 보내라고 피드백을 주어

    여러 요청을 보내더라도 순서가 보장된다.

    (PORT나 여러 정보 등을 필수로 넣도록 설계된 TCP가 너무 무겁다고 판단하여

    새로운 http버전에서는 하얀 도화지 상태에서

    PORT, 체크섬 정도만 추가하고 필요한 기능을 커스텀할 수 있는

    가벼운 프로토콜인 UDP의 입지가 강해지고 있다 한다.)

  4. TCP 세크먼트를 IP 주소가 적힌 IP 패킷으로 감싸 서버로 전송한다. 그럼 노드들을 왔다갔다 하며 IP주소와 일치하는 서버로 도착한다.

DNS

우리가 웹 주소를 검색할 때 www.google.com을 입력하지

100.100.100.1 이러지는 않는다.

www.google.com을 입력하면

도메인과 일치하는 IP 주소로 치환하여 요청을 보내주는데

DNS 서버가 그 역할을 한다.

우리가 돈내고 쓰는 인터넷 서비스 업체들이 그 역할을 한다.

URI, URL, URN

URI -> 인터넷의 우편물 주소 같은 것으로, 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다.

출처: https://mygumi.tistory.com/139 [마이구미의 HelloWorld]

URI의 형태로 URL과 URN이 있는 것인데,

URL은 흔히 쓰는 www.google.com과 같이 리소스의 구체적 위치를 서술하는 방식이다.

위치 뿐 아니라 리소스에 대입할 데이터도 보낼 수 있다.

URN은 리소스의 고유 이름을 통해 접근하는 방식이다.

주소는 변할 수 있어서, 보노보노에게 편지를 보내도 보노보노가 이사를 가버리면 편지는 전달되지 않는다. 하지만 애초에 보노보노에게 보내!라고 특정한 후 보내면 어디에 있든 찾아내 전달할 수 있다는 장점이 있다.

URN은 사용 방법이 정식으로 채택된 것이 없어 실제로 볼 일이 없다.

HTTP

stateless -> 서버에서 클라이언트가 준 내용을 기억하지 않기 때문에

클라이언트쪽에서 데이터를 보낼 때

필요한 내용을 전부 넣어서 보내게 만든다.

따라서 서버가 바뀌거나, 늘어나거나, 줄어들어도 클라이언트는 몰라도 된다.

클라이언트가 특정 서버에 의존적이지 않으므로 유지보수가 편리하다.

HTTP 메서드는 각각의 역할이 약속되어 있으며,

안전, 멱등, 캐시가능 여부 등에서 차이를 보인다,

  • 안전: 메서드를 호출할 때 리소스에 변화가 있는가?

    -> 값을 가져오기만 하는 메서드(GET, OPTIONS, HEAD 등)는 리소스 변화가 없으므로 안전,

    리소스에 변화를 주는 메서드(PUT, DELETE 등)은 안전하지 않음

  • 멱등: 여러 번 호출해도 결과가 같은가?

    -> ‘안전’한 메서드, 수정과 관련된 메서드 등은 100번 호출해도 결과가 같다.

    호출받으면 특정 동작을 수행하는 메서드(택배를 발송하는 로직을 수행하도록 구현된 POST 메서드)는 두 번 호출시 문제가 발생할 수 있다.(택배 발송을 두 번 누르면 택배가 두 번 발송된다거나)

  • 캐시 가능: 추가 예정

Updated:

You may also enjoy