Adventure Time - Jake 서버(Server)와 클라이언트(Client) | 소켓통신과 HTTP 통신
본문 바로가기
Network

서버(Server)와 클라이언트(Client) | 소켓통신과 HTTP 통신

by bogyoi 2024. 11. 7.

 

- 서버와 클라이언트가 무엇일까?

 

간단히 말해 서버와 클라이언트는 응답(Response)과 요청(Request) 이다.

 

클라이언트는 서비스를 요청하고, 서버는 이에 응하여 서비스를 제공한다.

 

서비스를 요청하는 주체에 따라 그 녀석이 클라이언트가 되는 것이다.

 

 


 

1. 소켓 통신

 

통신 방식에는 TCP/UDP 프로토콜을 기반으로 하는 소켓통신이 있다.

이는 서버와 클라이언트가 Port를 통해 통신을 하는 것이다.

 

TCP 소켓통신은 port를 통해 계속해서 연결을 하고 있기 때문에 실시간 통신에서 주로 사용되는 방식이다.

양방향 실시간 채팅의 경우 TCP방식의 소켓통신이나 웹소켓으로구현하는 것을 흔히 볼 수 있다. 

실시간으로 데이터를 처리해야하는 경우 http 통신이라면 계속해서 연결을 시도해야하기 때문에 부하가 들어 부적합할 수 있다.

따라서 실시간으로 데이터를 주고 받아야하는 스트리밍의 경우 Socket통신을 자주 사용하게 된다.

 

 


- 소켓통신의 과정

->  socket(소켓 생성)

-> bind(서버의 ip, port 설정)

-> listen(포트가 열린 상태로 연결 요청 대기중)

-> connect(클라이언트는 서버의 ip, port를 통해 연결 요청)

-> accept(연결 요청 수락)로 넘어가면 서버와 클라이언트 사이의 채널이 만들어지고 ,

한번 채널이 만들어지면 그 통로로 계속해서 양방향 통신을 할 수 있다. (이때 서버 역시 클라이언트에 요청을 보낼 수 있다. port로 연결이 될 때 처음 요청을 보내는 놈을 클라이언트라고 칭한다.)

응답을 받고서 연결이 끊어지는 것이 아니라 계속해서 연결이 된다는 뜻이다. 그러므로 HTTP에 비해 더 많은 리소스를 소모한다.

 

 

 

하지만 UDP의 경우는 listen-connect-accept 과정 없이 바로 통신을 하기 때문에 신뢰성을 보장하기 어렵다는 것이 특징이다.

 

TCP와 UDP는 같은 4계층 프로토콜이지만 성격이 다르다는 것을 알 수 있는데, 정말 간단히 말하면

데이터가 조금 손상이 되더라도 빠르게 보내는 것이 더 중요한 경우 UDP 통신 

데이터를 정확하게 보내는 것이 중요한 경우 TCP 통신. 

 

TCP와 UDP 의 통신방식

그림으로 살펴보면 TCP는 요청에 대한 ACK를 받으며 보다 신뢰성 있는 통신이 가능하다.

 

Differences between TCP and UDP - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

 

 

 

 

 

tcp/udp 차이

위의 영상이 TCP와 UDP의 통신 방식의 차이를 직관적으로 잘 설명해준다.

 


 

- HTTP 통신

 

우리가 알고있는 웹에서는 흔히 HTTP 통신 방식을 많이 이용한다.

물론 웹소켓이라는 양방향 실시간 통신 방식도 있다. 

필요할때마다 서버측에 요청(Request)를 던지고 서버는 클라이언트측에 응답(Response)를 보낸다.

따라서 필요한 경우에만 요청을 보내고 응답을 기다리는 것이다.

Client가 요청을 보내는 경우에만 Server가 응답을 하기 때문에 단방향 통신이라고 한다.

응답을 받고나면 연결이 종료되는 것이 특징이다.

웹소켓이 나오기 전, HTTP Polling(일정한 주기로 요청을 보내는 방법)으로 주기를 아주 짧게 잡아 실시간처럼 보이게 구현하는 방법이 있으나 요청 주기가 짧을 수록 부하가 커질 뿐더러 엄밀히 말하면 실시간이 아니다. 

그 외 HTTP Streaming(연결시간을 길게 가져가는 방식) 등의 방식이 있지만, 마찬가지로 상황에 따라 여러 성능 제약이 따른다.

이렇게 실시간 방식에 비효율적인 HTTP를 보완하기 위한 것이 웹소켓이라고 할 수 있다. 매번 연결을 하지 않기 때문에 오버헤드가 적다.


 

 

앞서 말한 tcp/udp 소켓통신에서는 패킷을 주고받는다면, HTTP통신에서는 Message를 주고 받는다고 한다.

서버는 Response message를, 클라이언트는 Request message를 보낸다.

 

 

이 메세지에는 공통적으로 헤더(header)와 바디(body)가 있고, 응답메시지에는 상태줄(Status line), 요청메시지에는 시작줄(Start line)가 있다.

 

body에는 데이터가 들어가고

header에는 목적지, 쿠키 등의 여러 추가정보가 들어간다.

대표적으로 클라이언트 측에서 서버에 요청을 보낼 때 담아보내는 GET, POST, .. 같은 HTTP method는 Start line에 들어간다. 그 외 요청주소(Request target), HTTP버전이 들어간다.

응답 메시지의 Status line에는 HTTP버전, 응답상태(Status code), 응답텍스트(Status text)가 들어간다.

 

참고로 데이터를 가져오는 요청에는 보낼 데이터가 없기 때문에 body가 없다.

 

 

 

 

응용 계층인 HTTP는 아래 전송계층의 프로토콜을 사용한다. 이때 HTTP프로토콜은 주로 TCP프로토콜을 사용하여 만든다(하지만 기존의 HTTP/1, HTTP/2와는 다르게 HTTP/3 에서는 UDP가 기본 프로토콜이다.

 

*이밖에도 여러 통신 프로토콜이 있으니 참고

 

[네트워크] 프로토콜

프로토콜

velog.io