부족한 네트워크 지식을 보충하기 위하여 내용을 정리했으며, 쉽고 간결하게 작성하기 위해 노력했습니다.
네트워크 간단한 개념
- 간단한 네트워크 용어를 정리한다.
✅ IP(인터넷 프로토콜)
- IP 주소(Internet Protocol address, IP address)는 컴퓨터 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 특수한 번호이다.
- 이 프로토콜은 지정한 IP 주소에 데이터를 전달하는 역할을 하고, 패킷(packet)이라는 통신 단위로 데이터를 전달한다.
- 패킷이란 무엇일까?
- 네트워크가 전달하는 데이터의 형식화된 블록이다.
IP 패킷 정보
출발지 IP, 목적지 IP, 기타 등이 포함되어 있다.
IP 패킷의 IP를 이용하여 서버에 요청을 보내기도 하고, 다시 클라이언트에 응답을 보내기도 한다.
하지만 IP는 몇가지 문제점을 가지고 있다.
IP 프로토콜의 한계
-
비신뢰성
- 패킷의 흐름에 관여하지 않기 때문에 보낸 정보가 제대로 갔는지 보장하지 않는다는 뜻이다.
- 패킷이 손상되거나 순서가 뒤바뀌어도 책임지지 않는다.
-
비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.
패킷 전송과 정확한 순서를 보장하려면 TCP 프로토콜과 같은 IP의 상위 프로토콜을 이용해야 한다.
✅ TCP
- 전송 제어 프로토콜(Transmission Control Protocol)은 인터넷 프로토콜(IP)의 핵심 프로토콜 중 하나로, IP와 함께 TCP/IP라는 명칭으로도 널리 불린다.
- IP의 문제점을 보완하여 데이터를 안정적으로 순서대로 에러없이 교환할 수 있다.
특징
-
TCP 3 way handshake (가상 연결)을 통하여 현재 네트워크 통신이 가능한지 알 수 있다.
- SYN : 접속 요청
- SYN + ACK : 접속 요청 + 요청 수락
- ACK : 요청 수락
-
지금 현재 네트워크 통신이 가능한지 여부를 판단한다. 클라이언트와 서버가 모두 요청과 수락이 확인되면 데이터를 전송한다. 따라서 데이터의 손실을 방지한다.
-
데이터를 전송하고 데이터 전송이 완료되면 연결을 종료한다.
✅ UDP
- TCP의 안정성을 필요로 하지 않는 애플리케이션의 경우 일반적으로 TCP 대신 사용자 데이터그램 프로토콜(User Datagram Protocol)을 사용한다.
- 전달 확인 및 순차 보장 기능이 없는 대신 오버헤드가 작고 지연시간이 짧다는 장점이 있다.
TCP vs UDP
-
TCP는 데이터를 주고 받을 양단 간에 먼저 연결을 설정하고 설정된 연결을 통해 양방향으로 데이터를 전송하지만, UDP는 연결을 설정하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계를 거치지 않고 단방향으로 정보를 전송한다.
-
신뢰성
- TCP는 메시지 수신을 확인하지만 UDP는 수신자가 메시지를 수신했는지 확인할 수 없다.
-
순서 정렬
- TCP에서는 메시지가 보내진 순서를 보장하기 위해 재조립하지만 UDP는 메시지 도착 순서를 예측할 수 없다.
-
부하
- UDP가 TCP보다 속도가 일반적으로 빠르고 오버헤드가 적다. TCP가 신뢰성을 위하여 더 많은 패킷정보를 가지고 있기 때문이다.
✅ PORT
- IP는 같지만 다양한 프로세스와 서비스를 구분하기 위하여 포트를 사용한다. 예를들어 HTTP(80), HTTPS(443)와 같이 같은 IP에서 다른 프로세스를 구분하기 위하여 포트를 사용한다.
- 0 ~ 1023 : 잘 알려진 포트 (well-known port)
- 1024 ~ 49151 : 등록된 포트 (registered port)
- 49152 ~ 65535 : 동적 포트 (dynamic port)
✅ DNS
- 컴퓨터의 주소를 찾기 위해 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호(IP 주소)로 변환해 준다.
🔥 HTTP
HyperText Transfer Protocol
- 처음 HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이였다.
- 이제는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이라고도 한다.
- 1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜이다. 현재는 HTTP/1.1 버전을 가장 많이 사용하고 있고 성능이 개선된 HTTP/2 버전도 사용하고 있다.
1️⃣ HTTP의 특징은?
- 지금 우리는 데이터를 주고 받기 위해 대부분 HTTP를 이용한다. 어떤 특징을 가지고 있는지 알아보자.
클라이언트 서버 구조
- Request-Response 구조로 이루어져 있다.
- 클라이언트에서 요청을 보내면 서버에서는 요청에 대한 결과를 만들어서 응답하는 구조이다.
무상태 프로토콜(Stateless)
- 서버가 클라이언트의 상태를 보존하지 않는다. 즉, 두 개의 요청 사이에는 연결고리가 없다.
- 서버는 요청에 대한 처리만 할 뿐 클라이언트의 상태에 대하여 알 수 없다.
- 따라서 서버를 확장할 때 유리하지만(스케일 아웃), 클라이언트에서 추가 데이터를 전송하야 한다.
- 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가된다.
비연결성(Connectionless)
- HTTP는 기본이 연결을 유지하지 않는 모델이다. 요청에 대한 연결을 유지하고 있으면 서버의 자원이 낭비되기도 한다. 따라서 서버의 자원을 효율적으로 사용할 수 있다.
- 하지만 문제는 클라이언트-서버의 상태를 확인하는 단계가 추가된다.(3 way handshake)
- 이러 문제들을 현재는 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다.
HTTP 요청 메시지
GET / HTTP/1.1
Host: developer.mozilla.org
HTTP 응답 메시지
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 29769(here comes the 29769 bytes of the requested web page)
참고 : HTTP 파이프라이닝이 활성화되면, 첫번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다. HTTP 파이프라이닝은 오래된 소프트웨어와 최신 버전이 공존하고 있는, 기존의 네트워크 상에서 구현하기 어렵다는게 입증되었으며, 프레임안에서 보다 활발한 다중 요청을 보내는 HTTP/2로 교체되고 있습니다.
단순함, 확장 가능
- HTTP 메시지는 간단한 구조로 이루어져 있다. 그리고 확장에 유용하다.
2️⃣ HTTP API 설계
-
API를 설계할 때 가장 중요한 것이 무엇일까?
- 가장 중요한 것은 리소스이다.
-
회원을 관리하는 API를 설계해보자. 회원을 등록하고, 수정하고, 삭제하는 것은 리소스가 아니다. 리소스는 회원이다.
-
행위의 주체가 되는 리소스를 식별하고 관리하는 것이 핵심이다.
-
회원을
member라고 하고, 나머지를 행위로 구분하여 API를 설계해야 한다.
/members/{조회ID}
/members/{등록ID}
/members/{수정ID}
/members/{삭제ID}
- 위와 같이 설계되어 있을때 어떻게 내가 원하는 행위를 구분할 수 있을까? 현재는 모두 URL이 같은데...
- 우리는 HTTP 메서드를 통하여 행위를 구분할 것이다.
HTTP 메서드 종류
GET
- 리소스(회원)를 조회한다.
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다.
POST
- 요청한 데이터를 처리하거나 메시지 바디를 통해 요청 데이터를 전달한다.
- 주로 리소스를 등록하고 프로세스 처리를 사용할 때 사용한다.
PUT
- 리소스를 수정할 때 사용한다. 하지만 주의해야할 점은 리소스의 전체를 대체한다는 것이다. 리소스의 일부분만 수정이 불가능하다.
- 완전히 리소스를 대체하기 때문에 사용할 때 주의를 요구한다.
PATCH
- PUT 과 같이 리소스를 수정한다. 다른 점이 있다면 PATCH는 부분 변경이 가능하기 때문에 변경하고 싶은 리소스만 수정할 수 있다.
DELETE
- 리소스를 제거한다.
3️⃣ HTTP 메서드의 속성
안전(Safe Methods)
- 호출해도 리소스를 변경하지 않는다.
멱등(Idempotent)
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다. 여러번 요청 시 결과가 다를 수 있다.
서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지 판단의 근거가 된다.
클라이언트에서 서버로 데이터 전송
정적 데이터 조회
- 이미지, 정적 텍스트 문서를 조회한다. 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능하다.
동적 데이터 조회
- 주로 검색, 게시판 목록에서 정렬 필터에 사용한다. GET은 쿼리 파라미터 사용해서 데이터를 전달
HTML Form 데이터 전송
- GET, POST 만 사용가능하다.
- HTTP 메서드로 해결하기 애매한 경우 컨트롤 URI를 사용한다.(HTTP API 포함)
- Content-Type: multipart/form-data
- Content-Type: application/x-www-form-urlencoded
HTTP API 데이터 전송
- HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용한다.(AJAX)
- POST, PUT, PATCH 메시지 바디를 통해 데이터를 전송한다.
- Content-Type: application/json을 주로 사용 (사실상 표준)
4️⃣ HTTP 상태코드
- 1xx (Informational): 요청이 수신되어 처리중
- 2xx (Successful): 요청 정상 처리
- 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
- 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
만약 모르는 상태 코드가 나타나면?
- 클라이언트는 상위 상태코드로 해석해서 처리한다. 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
2xx (Successful)
-
클라이언트의 요청을 성공적으로 처리
200 OK
201 Created
202 Accepted
204 No Content
3xx (Redirection)
-
요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
307 Temporary Redirect
308 Permanent Redirect -
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
4xx (Client Error)
-
클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없다.
-
오류의 원인이 클라이언트에 있기 때문에 클라이언트에서 수정이 필요한다.
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
5xx (Server Error)
-
서버 문제로 오류가 발생하는 경우다. 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있다.(복구가 되거나 등등)
500 Internal Server Error
503 Service Unavailable
학습에 도움이 되었던 자료
