[Q] HTTP 특징 및 장단점
[A]
HTTP(Hyper Text Transfer Protocol)란 데이터를 주고 받기 위한 프로토콜이며, 서버/클라이언트 모델을 따릅니다.
HTTP는 클라이언트의 상태 정보를 저장하지 않는 Stateless의 특징과 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless의 특징을 가지고 있습니다.
장점으로는 통신간의 연결 상태 처리나 상태 정보를 관리할 필요가 없어 서버 디자인이 간단하고, 각각의 HTTP 요청에 독립적으로 응답만 보내주면 되어 최소한의 자원으로 서버를 유지할 수 있어 확장성이 있습니다.
단점으로는 이전 통신의 정보를 기억하지 않기 때문에 매번 인증을 해줘야 합니다. 이를 해결하기 위해 쿠키(cookie)나 세션(session)을 사용해서 데이터를 처리합니다.
상세설명
HTTP (HyperText Transfer Protocol)란 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜로 80포트를 사용합니다. 초기에는 텍스트 형식만 가능했으나 현재는 JSON, Image 등 다양한 형식의 파일들을 전송할 수 있습니다.
HTTP 통신은 클라이언트에서 서버로 요청을 보내고, 서버가 이에 응답하는 방식으로 단방향 통신이 이루어집니다.
HTTP는 TCP/IP를 이용하는 응용 프로토콜입니다.
HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜로 요청/응답 방식으로 동작합니다.
HTTP는 무상태 프로토콜(Stateless)로 응답 서버를 쉽게 바꿀 수 있어 서버 확장에는 용이하지만 다시 연결할 경우 클라이언트가 추가 데이터를 전송해야 합니다. 이러한 단점을 해결하기 위해 Cookie와 Session이 등장하였습니다.
HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊습니다. 이를 통해 최소한의 자원으로 서버를 유지할 수 있습니다. 비연결형으로 웹페이지를 보는 중 인터넷 연결이 끊어졌다 다시 연결되어도 페이지를 계속 볼 수 있으나 재연결 시 TCP/IP 연결을 새로 맺어야하므로 3 way handshake 시간이 추가되고 웹 브라우저로 사이트를 요청하면 HTML, CSS, JavaScript, 추가 이미지 등 수많은 자원이 함께 다운로드 되어 재연결하는 것은 매우 비효율적입니다.
[Q] HTTP vs HTTPS
[A]
HTTPS(HyperText Transfer Protocol over Secure Socket Layer)는 HTTP에 보안이 강화된 버전의 프로토콜로 TCP/IP 포트인 443포트를 사용합니다. 소캣 통신에서 일반 텍스트를 이용하는 대신, 웹 상에서 정보를 암호화하는 TLS나 SSL 프로토콜을 사용하여 데이터를 암호화 합니다.
기밀성(사생활 보호), 데이터 무결성, ID 및 디지털 사용한 인증을 제공하고 보호 수준은 웹 브라우저의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 따라 달라집니다.
HTTPS의 장점으로는 네트워크 상에서 열람, 수정이 불가능하므로 보안성이 높다는 것 입니다.
단점으로는 HTTPS는 설치 및 인증서를 유지하는 데 추가 비용이 발생하고 암호화하는 과정이 웹 서버에 부하를 준다는 것입니다.
인증과정이 있어 HTTP에 비해 속도가 느리고 HTTPS는 소켓 자체에서 인증을 하기 때문에 인터넷의 연결이 끊기면 소켓도 끊어져 HTTPS 재인증이 필요합니다.
HTTP와 HTTPS의 차이는 문서 전송시 암호화 처리 유무입니다.
HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약하지만 HTTPS는 안전하게 데이터를 주고받을 수 있습니다. 하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리고 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생합니다.
그렇기 때문에 개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 사용하고, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 사용하는 것이 효율적입니다.
[Q] TCP vs UDP
[A]
TCP는 연결형 서비스로 3-way handshaking 과정을 통해 연결을 설정하기 때문에 높은 신뢰성을 보장하지만, 속도가 비교적 느리다는 단점이 있습니다.
UDP는 비연결형 서비스로 3-way handshaking을 사용하지 않기 때문에 신뢰성이 떨어지는 단점이 있지만, 데이터 수신 여부를 확인하지 않기 때문에 속도가 빠르다는 장점이 있습니다.
TCP는 신뢰성이 중요한 파일 교환과 같은 경우에 쓰이고 UDP는 실시간성이 중요한 스트리밍에 자주 사용됩니다.
상세설명
TCP(Transmission Control Protocol)는 연결 지향적 프로토콜입니다.
*연결 지향적 프로토콜은 클라이언트와 서버가 연결된 상태에서 데이터를 주고받는 프로토콜을 의미한다.
TCP는 장치들 사이에 논리적인 접속을 성립하기 위해 연결을 설정해 신뢰성을 보장하는 연결형 서비스로 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(데이터, 메시지, 세그먼트라는 블록 단위)을 안정적으로, 순서대로, 에러 없이 교환할 수 있게 합니다.
TCP의 특징
연결형 서비스로 가상 회선 방식을 제공
3-way handshaking 과정을 통해 연결을 설정하고, 4-way handshaking 과정을 통해 연결을 해제한다.
흐름 제어(Flow control)
데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지
혼잡 제어(Congestion control)
네트워크 내의 패킷 수가 과도하게 증가하지 않도록 방지
높은 신뢰성을 보장
신뢰성이 높은 전송을 하기 때문에 UDP보다 속도가 느림
전이중(Full-Duplex), 점대점(Point to Point) 방식
전이중(Full-Duplex) : 전송이 양방향으로 동시에 일어날 수 있다.
점대점(Point to Point) : 각 연결이 정확히 2개의 종단점을 가지고 있다.
UDP는 비연결형 프로토콜입니다.
※ 연결을 위해 할당되는 논리적인 경로가 없고, 각각의 패킷은 다른 경로로 전송되며, 독립적인 관계를 지닌다.
UDP의 특징
비연결형 서비스로 데이터그램 방식을 제공한다.
데이터의 전송 순서가 바뀔 수 있다.
데이터 수신 여부를 확인하지 않는다.
TCP의 3-way handshaking과 같은 과정 X
신뢰성이 낮다.
흐름 제어(flow control)가 없어서 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.
TCP보다 속도가 빠르다.
1:1 & 1:N & N:N 통신이 가능하다.
[Q] Cookie vs Session
[A]
쿠키는 사용자의 컴퓨터에 저장하는 기록 정보 파일입니다. HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요시 정보를 참조하거나 재사용할 수 있습니다.
세션은 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술입니다.
큰 차이점은 사용자의 정보가 저장되는 위치입니다.
쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 session-id만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높습니다.
쿠키는 쿠키에 정보가 있기 때문에 서버에 요청 시 속도가 빠르고, 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 속도가 느립니다.
세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버의 자원을 사용하기에 서버 자원에 한계가 있고, 속도가 느려질 수 있기 때문에 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있습니다.
[Q] 세션 기반 인증(Session / Cookie)이란?
[A]
세션 기반 인증이란 서버 측에서 사용자들의 정보를 기억하기 위해 세션을 유지하는데, 이는 메모리, 디스크, 데이터베이스 등을 통해 관리합니다. 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하여 유지해야 하므로 Stateful 한 구조를 가집니다.
인증 방식
- 사용자가 로그인 시 올바른 사용자임을 확인하고, 고유한 세션 ID 값을 부여해 세션 저장소에 저장하고 클라이언트에게 발급해준다.
- 클라이언트는 세션 ID를 받아 쿠키에 저장하고, 인증이 필요한 요청마다 쿠키에 세션 ID를 담아 헤더에 보낸다.
- 서버에서는 쿠키를 받아 세션 저장소와 비교해 올바른 요청인지 확인한다.
- 인증이 완료되고 서버는 요청에 응답한다.
장점으로는 중요한 정보는 서버에 있기 때문에 쿠키 자체(세션 ID)에는 유의미한 값을 가지고 있지 않아 보안성이 높다는 것입니다.
하지만 해커가 훔친 쿠키를 이용해 HTTP 요청을 보내면 서버에서는 올바른 사용자가 보낸 요청인지 알 수 없어(세션 하이재킹 공격) 세션에 유효시간을 넣어줘야 합니다.
서버에 세션을 저장하므로 사용자가 증가함에 따라 과부하를 줄 수 있어 확장성이 용이하지 못하고 시스템 확장이 어렵다는 단점이 있습니다.
[Q] Token 기반 인증(JWT)이란?
[A]
세션 기반 인증의 단점을 극복하기 위해 나온 것이 토큰 기반 인증 시스템 입니다.
인증받은 사용자에게 토큰을 발급해주고, 서버에 요청을 할 때 HTTP 헤더에 토큰을 함께 보내 인증받은 사용자(유효성 검사)인지 확인합니다.
서버 기반 인증 시스템과 달리 사용자의 인증 정보를 서버에 저장하지 않고 클라이언트의 요청으로만 인가를 처리하므로 Stateless한 구조를 가집니다.
인증 방식
- 사용자가 로그인 시 올바른 사용자임을 확인하고, 클라이언트에게 Access Token(JWT)을 발급해준다.
- 클라이언트는 전달받은 토큰을 저장해 두고, 인증이 필요한 요청마다 토큰을 HTTP 헤더에 담아 보낸다.
- 서버에서는 암호화된 토큰을 복호화 해 올바른 요청인지 확인한다.
- 인증이 완료되고 서버는 요청에 응답한다.
장점으로는 서버 기반 인증 시스템은 저장소의 관리가 필요하지만, 토큰 기반은 Access Token을 발급해준 후 요청이 들어오면 검증만 해주면 되기 때문에 추가 저장소가 필요 없어 Stateless한 구조입니다.
확장성이 뛰어나고 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다. Ex) facebook, Google 등
단점으로는 이미 발급된 JWT를 돌이킬 수 없고, 서버 기반 인증 시스템처럼 저장소를 사용하는 경우에는 해당 세션이 악의적으로 사용될 경우 지워버리면 되지만, JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능합니다.
JWT의 길이가 길고 인증이 필요한 요청이 많아질수록 서버의 자원 낭비가 발생합니다.
[Q] Token 기반 인증의 단점
[A]
이미 발급된 JWT를 돌이킬 수 없고, 서버 기반 인증 시스템처럼 저장소를 사용하는 경우에는 해당 세션이 악의적으로 사용될 경우 지워버리면 되지만, JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능합니다.
JWT의 길이가 길고 인증이 필요한 요청이 많아질수록 서버의 자원 낭비가 발생합니다.
[Q] JWT란?
[A]
JWT는 Json Web Token의 약자로 인증에 필요한 정보를 암호화시킨 토큰으로 세션/쿠키 방식과 유사하게 클라이언트는 Access Token(JWT)을 HTTP 헤더에 실어 서버로 보냅니다.
JWT 란 JSON 포맷을 이용해 사용자에 대한 속성을 저장하는 Claim 기반의 웹 토큰입니다.
JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달합니다.
※JWT는 주로 static 변수와 로컬 스토리지에 저장한다고 한다. static 변수에 저장하는 이유는 HTTP 통신을 할 때마다 JWT를 HTTP 헤더에 담아서 보내야 하는데, 이를 로컬 스토리지에서 계속 불러오면 오버헤드가 발생하기 때문이다.
JWT는 세 파트로 나누어지며, 각 파트를 점( . )으로 구분한다.
Header(헤더)는 토큰의 타입과 해시 암호화 알고리즘으로 구성된다.
alg는 헤더를 암호화 하는 것이 아닌, Signature를 해싱하기 위한 알고리즘을 지정하는 것이다.
Payload(내용)은 토큰에 사용자가 담고자 하는 정보를 담는 곳이다.
Payload에는 토큰에서 사용할 정보의 조각들인 Claim 이 담겨있고, 이는 JSON(Key/Value) 형태의 한 쌍으로 이루어져 있다.
Payload는 3가지로 구성되어 있는데 첫번째는 등록된 클레임(Registered Claim)이다.
등록된 클레임은 토큰 정보를 표현하기 위해 이름이 이미 정해진 종류의 데이터이다.등록된 클레임의 사용은 모두 선택적이지만, 사용할 것을 권장한다.
두번째는 공개 클레임(Public Claim)이다. 공개 클레임은 사용자 정의 클레임으로, 충돌이 방지된 이름을 가져야 하며, 충돌 방지를 위해 클레임 이름을 URI 형식으로 짓는다.
세번째는 비공개 클레임(Private Claim)이다. 비공개 클레임은 사용자 정의 클레임으로, 클라이언트와 서버가 협의하에 임의로 지정한 정보를 저장해서 사용한다.
Signature(서명)은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다.
헤더(Header)와 내용(Payload)의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀키를 이용해 헤더에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성한다.
위의 Header + Payload + Signature를 합치면 아래의 비밀스런 코드가 완성된다.
[Q] 트래픽 증가시 해결 방법
[A]
스케일 업을 통해 하드웨어 스펙을 향상 / 스케일 아웃을 통해 서버를 여러대 추가해 시스템을 증가
[Q] 로드 밸런싱이란?
[A]
네트워크 또는 서버에 가해지는 로드를 분산 해주는 기술로 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미합니다. 로드밸런싱은 여러 대의 서버를 두고 서비스를 제공하는 분산 처리 시스템에서 필요한 기술입니다.
로드 밸런싱 알고리즘
라운드 로빈 (Round Robin)
클라이언트의 요청을 여러 대의 서버에 순차적으로 분배하는 방식이다. 추가적인 계산작업이 없이, 들어온 요청을 빠르게 서버에 분산해 전송하는 1차원적인 주기능에 focus를 맞춘 방식이기 때문에, 가장 많이 사용되는 로드밸런싱 기법이다. 모든 서버의 스펙이 동일하거나 비슷한 경우에 사용된다.
가중 라운드 로빈 (Weighted Round Robin)
각 서버에 처리량(가중치)를 지정한 후, 가중치가 높은 서버에 클라이언트 요청을 우선적으로 전달하는 방식이다. 주로 서버의 트래픽 처리 용량이 다를 경우, 즉 특정 서버의 스펙(사양)이 더 좋을 경우 사용된다. 예를 들어, A 서버(가중치 3)와 B 서버(가중치 1)가 있고 로드 밸런서가 클라로부터 총 8개의 요청을 받았다면, A와 B 서버에 각 6개와 2개의 요청이 전달된다.
IP 해시 (IP Hash)
클라이언트의 IP 주소가 어떤 서버로 전달될지를 결정하는 방식이다. 클라이언트의 IP 주소가 바뀌지 않으면 동일한 서버로 요청이 보내지는 것을 보장한다. RR 방식과 달리, 서버에 Session clustering이 구성되어 있지 않은 경우에 주로 사용한다.
최소 연결 (Least Connection)
요청이 들어온 시점에 가장 적게 연결돼있는 서버에 요청을 전송하는 방식이다. 서버에 분배된 트래픽이 일정하지 않을 경우에 주로 사용한다.
최소 응답 시간 (Least Response Time)
서버의 현재 연결 상태와 응답 시간을 모두 고려하여 가장 적은 연결 수와 가장 짧은 응답 시간을 가지는 서버에 우선적으로 요청을 보내는 방식이다.
[Q] CORS (Cross Origin Resource Sharing, 교차 출처 리소스 공유)
[A]
CORS란 도메인이 서로 다른 2개의 사이트가 데이터를 주고 받을 때 발생하는 문제입니다.
예를 들어 domain-a.com ↔ domain-b.com으로 데이터를 주고 받을 시 따로 설정 하지 않으면 CORS 에러를 만나게 됩니다.
※ 브라우저는 보안 상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다.
따라서 다른 서버의 리소스를 불러오기 위해서는, 그 출처에서 CORS에 대한 내용을 Response의 헤더에 추가해줘야 합니다.
Access-Control-Allow-Orgin : 요청을 보내는 페이지의 출처 [ *, 도메인 ]
Access-Control-Allow-Methods : 요청을 허용하는 메소드. Default : GET, POST
Access-Control-Max-Age : 클라이언트에서 preflight 요청 (서버의 응답 가능여부에 대한 확인) 결과를 저장할 시간
Access-Control-Allow-Headers : 요청을 허용하는 헤더
[Q] 공인 IP vs 사설 IP
[A]
공인 IP는 인터넷 사용자의 로컬 네트워크를 식별하기 위해 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소이며, 외부에 공개되어 있는 IP주소로 전세계에서 유일한 IP 주소를 갖습니다.
사설 IP는 일반 가정이나 회사 내 등에 할당된 네트워크 IP 주소이며, IPv4의 주소부족으로 인해 서브넷팅된 IP이기 때문에 라우터(공유기)에 의해 로컬 네트워크상의 PC나 장치에 할당됩니다.
사설 IP 주소만으로는 인터넷에 직접 연결할 수 없고, 라우터를 통해 1개의 공인 IP를 할당하고, 라우터에 연결된 개인 PC는 사설 IP를 각각 할당 받아 인터넷에 접속 할 수 있습니다.
[Q] OSI 7 layer와 각 계층
[A]
OSI 7 계층은 네트워크 통신이 일어나는 과정을 7단계로 나눈 국제 표준화 기구(ISO)에서 정의한 네트워크 표준 모델입니다.
1계층 - 물리계층(Physical Layer)
주로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하는 물리적인 장비로 데이터 전기적인 신호(0,1)로 변환해서 주고 받는 기능을 합니다.
이 계층에서 사용되는 통신 단위는 비트(Bit)이며 이것은 1과 0으로 나타냅니다.
주로 사용되는 장비는 통신 케이블, 리피터, 허브 등이 있습니다.
2계층 - 데이터 링크계층(DataLink Layer)
물리계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 통신의 흐름을 안전하게 관리합니다.
프레임에 물리적 주소(MAC address)를 부여하고 에러검출, 재전송, 흐름제어를 수행합니다.
이 계층에서 전송되는 단위는 프레임(Frame)이며 주로 사용되는 장비는 브리지, 스위치, 이더넷 등(여기서 MAC주소를 사용)입니다.
-> 브릿지나 스위치를 통해 맥주소를 가지고 물리계층에서 받은 정보를 전달함.
3계층 - 네트워크 계층(Network Layer)
데이터를 목적지까지 가장 안전하고 빠르게 전달하는 역할을 합니다.
라우터(Router)를 통해 경로를 선택하고 주소를 정하고(IP) 경로(Route)에 따라 패킷을 전달합니다. > IP 패킷 헤더 내 수신 및 발신 주소를 포함
이 계층에서 전송되는 단위는 패킷(Packet)이고, 주로 사용되는 장비는 라우터입니다.
4계층 - 전송 계층(Transport Layer)
통신을 활성화하기 위한 계층으로 보통 TCP프로토콜을 이용하며, 포트를 열어서 응용프로그램들이 전송을 할 수 있게 하는 역할을 합니다.
만약 데이터가 왔다면 4계층에서 해당 데이터를 하나로 합쳐서 5계층에 던져 줍니다.
port 번호, 전송방식(TCP/UDP)을 결정합니다. > TCP 헤더 붙음
두 지점간의 신뢰성 있는 데이터를 주고 받게 해주는 역할을 하고 신호를 분산하고 다시 합치는 과정을 통해서 에러와 경로를 제어합니다.
5계층 - 세션 계층(Session Layer)
두 지점간의 프로세스 및 통신하는 호스트 간의 연결을 유지합니다.
세션 설정, 유지, 종료, 전송 중단 시 복구 등의 기능을 수행합니다.
TCP/IP 세션을 체결하고, 포트번호를 기반으로 통신 세션을 구성합니다.
API, Socket
6계층 - 표현 계층(Presentation Layer)
코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다룹니다.
예를 들면, EBCDIC로 인코딩된 문서 파일을 ASCII로 인코딩된 파일로 바꿔 주거나 해당 데이터가 TEXT인지, 그림인지, GIF인지 JPG인지의 구분 해주는 역할을 합니다.(ex. 데이터변환, 압축, 암호화 등)
JPEF, MPEG, GIF, ASCII 등
7계층 - 응용 계층(Application Layer)
최종 목적지로, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행합니다. > 네트워크 소프트웨어 UI 부분, 사용자의 입출력(I/O)부분
HTTP, FTP, SMTP, POP3, IMAP, Telnet 등과 같은 프로토콜이 있습니다.
[Q] Get vs Post
[A]
GET은 클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용되는 메서드입니다.
GET을 통한 요청은 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링 (query string) 이라고 부릅니다.
GET 요청은 캐시가 가능합니다. GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환합니다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있습니다.
GET 요청은 브라우저 히스토리에 남습니다.
GET 요청은 북마크 될 수 있습니다.
GET 요청은 길이 제한이 있습니다.
GET 요청은 파라미터에 사용자 입력값이 노출되기 때문에 보안성이 낮습니다. 때문에 데이터를 요청할 때만 사용 됩니다.
POST는 클라이언트에서 서버로 리소스를 생성하거나 업데이트하기 위해 데이터를 보낼 때 사용 되는 메서드입니다.
POST는 전송할 데이터를 HTTP 메시지 body 부분에 담아서 서버로 전송합니다.
POST 로 데이터를 전송할 때 길이 제한이 따로 없어 용량이 큰 데이터를 보낼 때 사용하거나 GET처럼 데이터가 외부적으로 드러나는건 아니라서 보안이 필요한 부분에 많이 사용됩니다. 하지만 데이터를 암호화하지 않으면 body의 데이터도 노출될 수 있습니다.
POST 요청은 캐시되지 않습니다.
POST 요청은 브라우저 히스토리에 남지 않습니다.
POST 요청은 북마크 되지 않습니다.
POST 요청은 데이터 길이에 제한이 없습니다.
[Q] Restful API란?
[A]
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것으로 REST의 원리를 따르는 API를 의미합니다.
REST API 설계원칙으로는
URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 합니다.
마지막에 슬래시 (/)를 포함하지 않습니다.
언더바 대신 하이폰을 사용합니다.
파일확장자는 URI에 포함하지 않습니다.
[Q] HTTP Method 종류
[A]
HTTP 메서드란 클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식 입니다. 서버가 수행해야 할 동작을 지정하는 요청을 보내는 방법입니다.
HTTP 메소드의 종류는 총 9가지가 있으나 주로 쓰이는 메소드는 5가지입니다.
주요 메소드
GET : 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)
DELETE : 리소스 삭제
기타 메소드
HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
[Q] Patch vs Put
[A]
PUT 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체합니다.(전체 변경)
리소스를 대체(덮어쓰기 - 값이 없으면 null처리), 해당 리소스가 없으면 생성
PATCH 메소드는 리소스의 부분적인 수정을 할 때에 사용됩니다.(일부 변경)
해당 리소스 부분만 변경(없으면 변경x)
[Q] 브라우저 동작 방식
[A]
- 사용자가 브라우저에 URL(www.naver.com)을 입력
- DNS 서버에 도메인 네임으로 서버의 진짜 주소를 찾음
- IP 주소로 웹 서버에 TCP 3 handshake로 연결 수립
- 클라이언트는 웹 서버로 HTTP 요청 메시지를 보냄
- 웹 서버는 HTTP 응답 메시지를 보냄
- 도착한 HTTP 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력
[Q] HTTP status code
[A]
200 OK
가장 일반적으로 많이 사용하는 Status Code로 요청이 성공했음을 의미합니다.201 Created
회원가입(유저 생성), 글 작성 등 어떠한 리소스의 생성을 성공적으로 완료했을 때 사용하는 Status Code로 일반적으로 POST 요청에서 많이 사용합니다.400 Bad Request
주로 Query Parameter나 Request Body로 들어오는 데이터의 형식이 올바르지 않을 때와 같이 서버가 요청을 이해할 수 없는 상황에서 사용합니다.
ex) 회원가입 시 올바르지 않은 아이디/비밀번호 형식, 필수로 요구하는 Query Parameter를 누락했을 때401 Unauthorized
인증되지 않은 상태에서 인증이 필요한 리소스에 접근할 때 사용하는 Status Code입니다. 주로 Access Token를 요구할 때 유효하지 않은 Token을 받았을 때 응답했습니다.
ex) 로그인하지 않은 상태에서 자신의 사용자 정보 요청, 로그인하지 않은 상태에서 글 작성403 Forbidden
인증된 상태에서 권한이 없는 리소스에 접근할 때 사용하는 Status Code입니다. 예를 들어 로그인을 한 상태에서 다른 유저의 좋아요 상태를 변경시키는 API를 호출하는 경우 이 Status Code를 사용했습니다.
ex) 로그인했지만 다른 유저의 비밀번호를 변경하는 API 요청한 경우404 Not Found
주로 찾고자 하는 리소스가 없을 때, 요청한 API Route가 존재하지 않을 때 사용했습니다.405 Method Not Allowed
해당 HTTP Method에 대해서 요청을 막기 위한 용도로 사용하는 Status Code로 주로 특정 Method에 대해서 처리를 구현하지 않았을 때(해당 메서드를 지원하지 않을 때) 사용했습니다.409 Conflict
요청이 현재 서버의 상태와 충돌될 때 사용하는 Status Code로 이미 회원가입된 유저에 대해서 다시 회원가입을 시도할 때 등의 상황에서 사용했습니다.
ex) 이미 좋아요 처리된 아이템에 대해서 다시 좋아요 요청을 했을 때413 Payload Too Large
Payload의 크기가 서버에서 정의한 한계보다 클 때 사용하는 Status Code입니다. 파일 등을 전달받을 때 파일의 크기가 정의한 값보다 큰 경우와 같은 상황에서 사용했습니다.500 Bad Gateway
서버에서 예외처리되지 않은 오류에 대해서 처리할 때 이 Status Code를 사용합니다. 서버가 동작하지 않을 수 있는 상황이기 때문에 이 Status Code가 응답되었을 때 어떤 이유 때문에 이 Code가 응답되었는 지 잘 살펴봐야 합니다.
ex) 데이터베이스 오류, 예외처리하지 않은 오류 발생
[Q] Web Server vs WAS (Web Application Server)
[A]
웹 서버란 HTTP 프로토콜을 기반으로 클라이언트가 웹 브라우저에서 어떠한 요청을 하면 그 요청을 받아 정적 컨텐츠(HTML 문서, CSS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠)를 제공하는 서버입니다.
또한 동적 컨텐츠를 요청받으면 WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트에게 전달하는 역할도 합니다.
웹 서버에는 Apache, NginX 등이 있습니다.
WAS란 DB 조회 혹은 다양한 로직 처리를 요구하는 동적 컨텐츠를 제공하기 위해 만들어진 Application 서버입니다. HTTP 프로토콜을 기반으로 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서, 주로 데이터베이스 서버와 같이 수행됩니다.
WAS는 JSP, Servlet 구동환경을 제공해주기 때문에 서블릿 컨테이너 혹은 웹 컨테이너로도 불립니다.
이러한 WAS는 웹 서버의 기능들을 구조적으로 분리하여 처리하고자 하는 목적으로 제시되었고 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용됩니다. WAS는 프로그램 실행 환경과 DB 접속 기능을 제공하고, 여러 개의 트랜잭션을 관리할 수 있고, 비즈니스 로직을 수행할 수 있다.
WAS에는 Tomcat, JBoss, WebSphere 등이 있습니다.
[Q] IPv4 vs IPv6
[A]
IPv4는 3자리 숫자가 4마디로 표기되는방식이다. 각 마디는 옥텟(octet)이라고 부른다. Pv4는 한 옥탯당 256개(2^8)의 수를 나타낼 수 있어 256^4개의 주소를 만들 수 있다. 약 42억 개의 IP를 각각의 컴퓨터에 할당할 수 있는 것이다. 하지만 인터넷 환경이 발달함에 따라 어마어마하게 많은 수의 IP주소가 필요해져 IPv4 주소 체계로는 IP주소를 할당하기가 어려워졌다. 따라서 새로운 주소 체계인 IPv6가 나오게 되었다.
IP 주소는 대역에 따라 A,B,C,D,E 클래스로 나뉜다. 이 클래스들을 구분함으로써 클래스 내에서 Network ID와 Host ID를 구분하게 된다.
A Class : 대규모 네트워크 환경에 쓰이며, 첫번째 마디의 숫자가 0~127까지 사용된다. (ex : 12.123.123.123)
B Class : 중규모 네트워크 환경에 쓰이며, 첫번째 마디의 숫자가 128~191까지 사용된다. (ex : 128.123.123.123)
C Class : 소규모 네트워크 환경에 쓰이며, 첫번째 마디의 숫자가 192~223까지 사용된다. (ex : 192.168.0.1)
D Class : 멀티캐스팅용으로 쓰이며 잘 쓰이지 않는다.
E Class : 연구/개발용 혹은 미래에 사용하기 위해 남겨놓은 클래스로 일반적인 용도로 사용되지 않는다.
IPv6는 IPv4와 다르게 32비트가 아닌 128비트 체계의 인터넷 프로토콜을 의미한다. 즉 2^128개의 주소를 할당할 수 있다. IPv6는 각 16비트씩 8자리로 각 자리를 ':'으로 구분한다.
문제는 아직까지도 IPv4에서 IPv6로의 전환이 완료되지 않았다는 점이다. 아직까지도 많은 라우터들은 IPv4를 사용한다. IPv6로의 전환은 많은 시간과 비용이 들기 때문에 완료되기까지 적지 않은 세월이 걸릴 것이다. 현재는 IPv4와 IPv6를 혼용해서 사용하는데, IPv4 라우터에서는 tunneling이라는 방식을 사용해 IPv6 데이터그램을 전송한다.