API URI 설계

• URI의 역할은 리소스를 식별하는 것이기 때문에 URI에 행동을 담아선 안 됩니다. 즉, 회원 조회에서 회원은 리소스이고 조회는 행동이기 때문에 URI에는 회원에 대한 리소스만을 표현해야하며 행위는 HTTP 메소드로 표현해야 합니다.

• 서비스가 커질 경우 URI를 리소스만을 가지고 표현이 불가능할 수도 있습니다. 이럴 경우 예외적으로 /orders/{orderId}/start-delivery와 같이 행위를 URI에 담는 경우도 있습니다. 이를 컨트롤 URI라고 부릅니다.

GET

• GET 메서드는 주로 리소스를 조회하기 위한 목적으로 사용됩니다.

• 서버에 전달하고 싶은 데이터는 query를 통해서 전달합니다.

• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장되지 않습니다.

POST

• 데이터 생성을 요청하거나 특정 프로세스를 요청하기 위한 목적으로 사용됩니다.

• 요청에 필요한 데이터는 주로 바디에 담아서 요청합니다.

• 다른 메서드로 처리하기 애매하거나 불가능할 때 주로 POST를 사용합니다.

PUT

• 리소스를 대체하거나 해당 리소스가 없으면 생성해야 할 때 사용합니다.

• 서버에 name, age 데이터가 있는 상태에서 name만을 PUT으로 요청하면 기존 서버에 있는 name과 age를 없애고 이번에 요청한 name으로 대체할 때 사용합니다.

PATCH

• 리소스를 부분 업데이트할 때 사용합니다.

DELETE

• 리소스를 삭제할 때 사용합니다.

• body는 사용할 수 없기 때문에 만약, 삭제 시 body가 필요하다면 주로 POST로 대체합니다.

기타 HTTP 메서드

HEAD

• GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환합니다. 주로 캐시된 데이터가 최신인지 여부를 확인할 때 사용하는 메서드입니다.

OPTIONS

• 대상 리소스에 대한 통신 가능 옵션을 확인할 때 사용합니다. 주로 CORS의 Preflight Request에서 본 요청이 가능한지 여부를 확인할 때 사용합니다.

HTTP 메서드의 속성

안전( Safe Method )

• 리소스를 변경하지 않는 메서드를 안전 메서드라고 합니다.

멱등성( Idempotent )

• 한 번 호출하든 여러 번 호출하던 결과는 똑같은 메서드를 멱등 메서드라고 합니다.

• GET, PUT, DELETE는 여러 번 호출해도 결과는 똑같기 때문에 멱등 메서드입니다.

• 예를들어서 POST로 결제를 요청할 경우 여러 번 호출할 수록 결제가 여러 번 되기 때문에 비멱등 메서드입니다.

• 멱등과 비멱등을 구별해야 하는 이유는 클라이언트가 메서드에 대한 응답을 제대로 못받았을 때 해당 요청을 다시 해도 되는가?를 판단할 때 사용합니다.

캐시 가능( Cacheable )

• HTTP 메서드에 따라서 응답 결과 리소스를 브라우저에 캐시하는 것을 의미합니다.

• GET, HEAD, POST, PATCH는 캐시가 가능한 메서드입니다. 하지만, POST와 PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않기 때문에 주로 GET, HEAD만 캐시로 사용합니다.

HTTP 메시지 구조

• start-line, HTTP header, empty line 공백 라인(CRLF), message body 구조로 되어있습니다.

start-line

• start-line은 request-line과 status-line이 있습니다. 요청 메시지는 request-line이라 하고, 응답 메시지는 status-line이라고 합니다.

request-line

request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

• request-line은 요청 메시지로서 위와 같은 구조로 되어있으며 request-target은 절대 경로를 사용합니다.

status-line

status-line = HTTP-version SP status-code SP reason-phrase CRLF(엔터)

• status-line은 응답 메시지로서 위와 같은 구조로 되어 있습니다.

HTTP header

header-field = field-name":" OWS field-value OWS ( OWS : 띄어쓰기 허용 )

• header는 위와같은 구조로 되어있으며 field-name과 ":" 사이에 띄어쓰기는 허용하지 않습니다.

• field-name은 대소문자를 구분하지 않으며, field-value는 대소문자를 구분합니다.

HTTP header의 용도

• HTTP header에는 HTTP 전송에 필요한 모든 메타 데이터가 포함되어 있습니다. 예를들어서 메시지 바디의 부가정보, 메시지 바디의 크기, 압축 여부, 인증, 요청 브라우저 정보, 서버 애플리케이션 정보, 캐시 관리 정보등이 포함되어 있습니다. 경우에 따라서 필요한 임의의 헤더도 추가할 수 있습니다.( 약속한 클라이언트와 서버만 이해 가능 )

empty line 공백 라인(CRLF)

• empty line은 body와 상관없이 http 메시지에서는 반드시 있어야 하는 파트입니다.

HTTP 메시지 바디

• 실제 전송할 데이터로서 HTML 문서, 이미지, 영상, JSON, 등등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있습니다.

HTTP/0.9

• HTTP의 시작은 1989년 팀 버너스 리(Tim Berners-LEE)에 의해 시작되었습니다. 초기 버전인 HTTP/0.9는 매우 단순한 프로토콜로서 GET 동작이 유일했으며 헤더와 상태 코드(status code)도 없었기 때문에 문제가 발생한 경우 특정 html 파일에 오류에 대한 설명과 함께 응답하였습니다.

HTTP/1.0

• HTTP/1.0이 발표되면서 지금의 HTTP의 메시지 구조와 동일한 형태가 만들어졌습니다. HTTP/1.0 부터 시작 라인에는 메서드, PATH, HTTP 버젼 응답일 경우에는 status code가 기재되었습니다. 헤더가 추가되어 다양한 속성을 지정할 수 있었으며, 특히 Content-Type 덕분에 HTML 파일 뿐만 아니라 다른 형식의 파일도 전송할 수 있게 되었습니다.

HTTP/1.0의 문제점

• HTTP 1.0에서부터 야기된 문제점은 하나의 요청과 응답마다 연결 및 종료가 반복되는 것이었습니다. 예를 들어서 웹 페이지를 요청하면 html과 그에 딸린 css, js, 이미지 등의 수많은 각각의 자원들을 요청하고 수신 받기 위해 불필요한 TCP 연결과 종료를 반복 수행합니다.
  특히 TCP는 안정적인 송.수신을 위해 연결 시 마다 3-way-handshake 작업이 필요하고, 혼잡 제어 기능으로 인해 Slow Start로 초기 전송 속도가 느리다는 특징이 있기 때문에 HTTP에서 위와 같은 문제점은 상당히 부각될 수 있습니다.

HTTP/1.0+의 keep-alive

• keep-alive는 사용하지 않기로 결정되어 HTTP/1.1 명세에서 빠졌지만, 아직 많은 브라우저와 서버는 이 초기 keep-alive 커넥션을 사용하고 있습니다. 그리고 그 설계상의 문제는 HTTP1/1.1에서 보완하여 '지속 커넥션'으로 재탄생 하였습니다.

HTTP/1.0+ keep-alive 사용법

• 사용 방법으로는 HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection:Keep-alive 헤더를 포함시킵니다. 이 요청을 받은 서버는 그 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답합니다. 만약, 응답에 Connection:Keep-alive 헤더가 없으면 클라이언트는 서버가 keep-alive를 지원하지 않으며, 응답 메시지가 전송되고 나면 서버가 커넥션을 끊을 것이라 추정합니다.

HTTP/1.0+ keep-alive 옵션

• keep-alive 헤더는 커넥션을 유지하기를 바라는 요청일 뿐입니다. 클라이언트나 서버가 keep-alive 요청을 받았다고 해서 무조건 그것을 따를 필요는 없습니다. 언제든지 keep-alive 커넥션을 끊을 수 있으며 keep-alive 커넥션에서 처리되는 트랜잭션의 수를 제한할 수도 있습니다. keep-alive의 동작은 keep-alive 헤더의 쉼표로 구분된 옵션들로 제어할 수 있으며, 이를 통해 지속 시간과 응답의 개수(이대로 동작한다는 보장은 없음)를 지정할 수 있습니다.

keep-alive와 멍청한( dumb ) 프락시

• dumb 프락시는 클라이언트가 요청한 Connection:Keep-Alive 헤더를 이해하지 못하고 그대로 서버에 전달하였을 때 문제가 발생됩니다. 클라이언트와 서버는 Keep-Alive를 유지하지만 Dumb 프록시는 이를 이해하지 못하고 잘못된 처리를 하거나 연결을 끊어버리기 때문에 클라이언트 입장에서는 다시 연결하여 요청을 보내야 하고, 서버 입장에서는 클라이언트와 연결이 끊긴줄 모르기 때문에 연결 정보를 유지하는데 리소스를 낭비합니다.
  
  이러한 문제를 해결하는 차선책으로 Proxy-Connection이라는 비표준 헤더를 추가하여 똑똑한 프락시는 이를 Connection:Keep-Alive를 지원하기 때문에 Proxy-Connection:Keep-Alive 에서 Connection:Keep-Alive로 변환하여 서버에 전달합니다. 하지만, 이 또한 똑똑한 프락시 다음에 멍청한 프락시가 올 경우 동일한 문제가 발생됩니다.

HTTP/1.1

• HTTP/1.1 표준은 이전 버전에서 발견된 프로토콜 모호성 및 성능을 개선하기 위해 도입되었습니다. 커넥션과 관련한 기술로는 지속 커넥션과 파이프라이닝 커넥션이 추가되었습니다.

HTTP/1.1의 Chunked Encoding

• Chunked Encoding은 HTTP 메시지 본문을 일정한 크기의 Chunk로 분할하여 전송하는 방식을 의미합니다. 즉, 클라이언트에서 서버 또는 서버에서 클라이언트로 요청 및 응답할 때 사용할 수 있습니다.
  
  
• 나누어진 각각의 Chunk는 길이 필드와 Chunk 데이터로 구성됩니다. 길이 필드는 16진수로 표시되어 Chunk 데이터의 바이트 수를 나타내며, 이를 통해 수신측에서 각각의 Chunk를 구분할 수 있으며, 마지막 Chunk의 길이가 0으로 표시합니다. Chunked Encoding 사용하면은 Content-Length를 사용할 필요가 없습니다.
  
  
• 이러한 Chunked 방식을 통해서 메시지 요청이 끝나지 않았어도 일부 응답 데이터를 만들어 응답할 수 있습니다. 그리고 너무 큰 응답 데이터에 대해서 Chunked Encoding 방식으로 분할하여 응답할 때도 유용합니다.
  
  
  

HTTP/1.1의 지속 커넥션

• HTTP/1.1에서는 HTTP/1.0+의 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 지원합니다. 지속 커넥션은 기본적으로 활성화되어 있으며 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection:close 헤더를 명시해야 합니다. 그리고 클라이언트와 서버는 언제든지 커넥션을 끊을 수 있으며 Connection:close를 보내지 않는다고 해서 영원히 커넥션을 유지하겠다는 것을 뜻하지 않습니다.
  
  
• HTTP/1.1은 HTTP/1.0+의 keep-alive와 달리 기본적으로 활성화 되어 있기 때문에 dumb 프락시가 Connection 헤더를 잘못 이해하여 잘못된 처리를 하거나 연결을 끊어버리는 상황이 상대적으로 적습니다. 하지만, 여전히 dumb 프락시가 지속 커넥션 또한 이해하지 못하는 경우가 있어 잘못된 처리를 할 수 있기 때문에 똑똑한 프락시를 사용하거나 Dumb 프록시에 대한 문제를 해결하는 기능이 내장되어 있는 HTTP/2.0을 사용하는 것이 좋습니다.

파이프라인 커넥션

• HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝 할 수 있습니다. 이를 통해 클라이언트는 요청을 연속으로 여러 개를 보낼 수 있어 지속 커넥션의 성능을 더 높여줍니다.

HLOB( Head of Line Blocking )

• 파이프라인 커넥션을 통해서 여러개의 요청을 한 번에 보낼 수 있습니다. 하지만, 서버는 요청 순서에 맞게 응답을 처리해야 하기 때문에 첫 번째 요청이 오래 걸리는 요청이라면 두 번째, 세 번째 요청이 그만큼 지연될 수 밖에 없습니다. 이러한 현상을 HOLB( Head of Line Blocking )이라고 합니다. HTTP/2.0에서는 멀티플렉싱 알고리즘으로 대체되었습니다.

Domain Sharding

• 파이프라이닝을 대체하기 위해 차선책으로 나온 기술이며, 브라우저들은 하나의 도메인에 대해 여러 개의 Connection을 생성하여 병렬로 요청을 보내고 받는 방식으로 성능을 개선하였습니다. 예를들어서 한 도메인당 6~13개의 TCP 연결들을 동시 생성해 여러 리소스를 한 번에 다운로드 하며 이를 Domain Sharding이라고 부릅니다.
  
  하지만, Domain의 주소를 찾기 위해 DNS Lookup 과정과 Connection으로 인한 추가적인 작업 및 메모리가 필요하다는 단점이 있습니다. 그렇기 때문에 HTTP/2.0 부터는 멀티 플렉싱을 통해 하나의 TCP 연결에서 여러 개의 요청과 응답을 처리할 수 있기에 사용되지 않습니다.

HTTP/1.1의 헤더 중복

• HTTP/1.1의 헤더에는 많은 메타 정보들을 담을 수 있습니다. 또한 cookie에 대한 활용도도 높아졌기 때문에 매 요청시 마다 전송하려는 값 보다 헤더의 값이 더 큰 경우가 많아졌습니다. 그리고 지속 커넥션 속에서 주고 받는 연속된 요청 데이터가 중복된 헤더값을 가지고 있는 경우가 많아 쓸데없는 네트워크 트래픽량이 증가하게 되었습니다.

HTTP/2.0

• HTTP/2.0은 기존 HTTP/1.1 버전의 성능 향상에 초점을 맞춘 버전입니다. HTTP/1.1까지는 한 번에 하나의 파일만 전송이 가능했습니다. 비록 파이프라이닝 기술이 있었지만, 파이프라이닝은 HOLB의 문제 때문에 잘 활용되지 못했습니다.
  
  
• HTTP/2.0은 HTTPS를 사용하는 경우에만 사용될 수 있습니다.

HTTP/2.0 Binary Framing Layer

• HTTP/1.1 이전 버전들은 text 형태로 전송되었던 것과 달리 HTTP/2.0부터는 HTTP 계층 최 하단에 Binary Framing 계층을 두어 Binary Framing 계층에서 메시지를 프레임 단위로 나누고 인코딩하여 Binary Frame 단위로 송.수신합니다. 그리고 헤더와 바디가 Layer로 구분되고, 이로 인해 데이터 파싱 및 전송 속도가 증가하였고 오류 발생 가능성이 줄어들었습니다. 각각의 프레임마다 데이터의 길이를 가지고 있기 때문에 Content-Length 헤더는 HTTP/2.0부터는 사용되지 않습니다.
  
  
  
  
• 텍스트 기반이 아닌 바이너리로 인코딩 하였을 때 이점을 예로 들자면, 0과 1로 이루어진 이미지 파일을 텍스트로 기반으로 인코딩 한다면은 0은 아스키 코드로 48이고 1은 아스키 코드로 49입니다. 즉, 텍스트 기반으로 통신할 경우 요청과 응답의 데이터 크기가 훨씬 더 커집니다.

stream과 fame 단위

• HTTP/1.1에서는 HTTP 요청과 응답은 Message 단위밖에 없었습니다. 하지만, HTTP/2.0 부터는 Message라는 단위 외에 Stream, Frame 이라는 단위가 추가되었습니다.

• Frame : HTTP/2.0에서는 통신의 최소 단위이며, Header 혹은 Data가 들어있습니다. 프레임은 스트림 ID, Length, Type(헤더, 바디, 데이터 등의 프레임의 타입 등을 의미), Flags(스트림의 종료 등), Payload 등으로 구성되어 있습니다.

• Message : HTTP/1.1과 마찬가지로 요청, 응답의 단위이며 다수의 Frame으로 이루어진 단위입니다. 클라이언트 또는 서버측은 수신받은 여러 프레임을 하나의 메시지로 완성하여 이를 처리할 수 있습니다.

• Stream : 연결된 Connection 내에서 Frame을 주고 받는 하나의 흐름입니다. 하나의 요청 및 응답을 통해 만들어진 바이너리 프레임은 하나의 스트림에 속하여 송.수신됩니다. 이렇게 하나의 요청, 응답에서 만들어진 여러 바이너리 프레임들은 하나의 스트림에 속해야 하는데, 그 이유는 수신측에서 하나의 스트림을 통해 프레임들을 순서대로 받아야 메시지를 만들 수 있기 때문입니다.

• HTTP/2.0은 HTTP 요청을 여러개의 Frame들로 나누고, 이 Frame들이 모여 요청/응답 Message가 되고, Message는 특정 Stream에 속하여 여러개의 Stream은 하나의 Connection에 속하게 되는 구조입니다. 즉, Stream에 속한 Message를 이루는 여러개의 Frame들이 Connection 내에서 병렬적으로 빠른 송.수신 처리를 할 수 있습니다.

Multiplexing

• HTTP/2.0은 Message를 Frame 단위로 쪼갠 후 stream을 이용하여 요청 및 응답을 송.수신합니다. 여기에 Multiplexing을 도입하여 하나의 커넥션으로 여러 개의 스트림을 통해 동시에 병렬적으로 메시지에 대한 여러 Frame을 응답 순서에 상관없이 주고 받을 수 있습니다.

Server Push

• HTTP/2.0은 클라이언트가 요청한 데이터를 분석하여 서버에서 필요할것 같은 리소스에 대한 추가적인 응답을 할 수 있습니다. 예를들어서 클라이언트가 HTML 파일을 요청했을 때 HTML 문서가 링크하고 있는 CSS, JS 파일을 미리 서버에서 응답할 수 있습니다.

Stream Prioritization

• 하나의 Connection에 여러 요청과 응답이 뒤섞여 버리면 응답을 받았을 때 종속된 프레임이 도착하지 못하는 상황이 발생될 수 있습니다. 이러한 상황을 예방하기 위해서 스트림의 1~256까지 우선순위를 두어 우선순위 높은 스트림을 보다 빠르게 처리할 수 있습니다.
  
  Stream Prioritization은 하나의 커넥션 내에 있는 여러 스트림들 간의 우선순위를 지정하는 기술입니다. 이를 통해 먼저 처리되어야 할 요청 및 응답을 담당하는 스트림에 높은 우선순위를 매겨 지연 시간을 최소화하고 성능을 향상시킬 수 있습니다. 스트림의 우선순위는 1~256 사이의 숫자로 표현할 수 있습니다. 숫자가 낮을수록 우선순위가 높습니다.
  
  또한 부모 스트림과 자식 스트림간의 종속 관계를 통해 같은 우선순위를 가졌음에도 먼저 처리되어야 할 스트림을 지정할 수 있습니다. 이는 HTML 파일을 처리하는 스트림을 부모로 두고 HTML에 필요한 CSS, JS 파일등을 처리하는 스트림을 자식으로 두어서 조금 더 빠르고 효율적으로 처리할 수 있습니다.
  
  Priority 프레임을 이용해서 자식 스트림의 우선순위를 변경할 수도 있습니다. 이때 자식 스트림은 부모 스트림보다 높은 우선순위를 가질 수 없습니다. (Priority 프레임은 스트림의 우선순위를 업데이트하기 위한 프레임으로, 프레임 헤더와 우선순위 정보를 포함하며, 종속관계가 있는 스트림일 경우 부모 스트림의 ID 또한 포함됩니다.)

Header Data Comperssion

• HTTP/1.1에서 헤더는 아무런 압축 없이 그대로 전송되었으며, 연속적으로 요청되는 HTTP 메시지의 헤더 값이 중복되는 부분들이 많아 네트워크 트래픽을 낭비하는 현상이 발생되었습니다. HTTP/2.0 부터는 HPACK 압축 알고리즘을 사용하여 중복된 헤더를 제거하고, 헤더에 대한 값을 압축 인코딩하여 네트워크 트래픽을 줄였습니다.
  
  
• HPACK 압축 알고리즘은 정적, 동적 테이블과 Huffman 압축 인코딩을 사용하는데, HTTP/2.0을 지원하는 환경에서는 모두 동일한 정적 테이블을 가지며, 자주 사용되는 헤더에 대한 정보를 가지고 있습니다. 이를 기반으로 통신하는 과정에서 동적으로 추가되는 헤더에 대한 인덱스를 생성하고 공유하여 이후 해당 헤더를 사용할 때는 이름이 아닌 index만을 기재합니다.
  
  그리고 헤더에 대한 데이터는 Huffam 압축 인코딩을 통해서 압축하여 송.수신합니다. 이렇게 정적, 동적 테이블과 Huffman 압축 인코딩을 통해서 중복된 헤더를 제거하고 데이터를 압축하여 네트워크 트래픽량을 줄일 수 있습니다.

DNS() Domain Name System )이란?

• DNS( Domain Name System )은 Domain 이름을 IP 주소로 변환하는 서비스를 제공하는 시스템입니다.

DNS의 다층적 구조

• DNS는 한 곳에서만 관리하는 것이 아닌 여러 서버에서 다층적으로 관리됩니다.

클라이언트가 도메인을 통해 서버에 접속하는 과정

1. 사용자가 도메인을 통한 웹 서버 접속을 시도
2. 로컬 컴퓨터에 도메인에 대한 IP 캐시 데이터가 없다면 로컬 DNS에 요청합니다.
3. 로컬 DNS에도 해당 도메인에 대한 IP 주소가 없다면 루트 DNS에 요청합니다.
4. 루트 DNS는 도메인에 따라서 .com, .net, .org... 들 중 하나의 DNS의 DNS 서버 IP주소를 응답합니다.
5. .com이라면 naver.com의 IP주소를 응답합니다.
6. 로컬 DNS는 naver.com의 DNS에 요청하며 호스트 네임에 맞는 IP주소를 응답합니다.
7. 최종적으로 로컬 DNS는 www.naver.com에 대한 IP주소를 응답하고 클라이언트는 해당 IP주소로 웹 서버에 접속합니다.

A Record, CName

A Record

• 도메인을 서버의 IP로 직접 연결할 때 사용합니다.

CName

• IP가 유동적으로 변하는 서버의 경우 A Record가 아닌 CName을 도메인에 등록하면 AWS의 EC2와 같이 유동적으로 IP가 변하는 환경에서도 DNS에 도메인을 등록할 수 있습니다.( AWS에서도 설정을 통해 고정 IP를 제공 받을 수 있습니다. )

HTTPS( HyperText Transfer Protocol over Secure )란?

• HTTPS( HyperText Transfer Protocol over Secure )는 HTTP에 SSL/TLS을 이용하여 HTTP의 body를 암호화하여 서버와 클라이언트 간의 안전한 통신을 보장하는 프로토콜입니다.

HTTPS를 사용해야 하는 두 가지 이유

• HTTP를 사용하면 클라이언트와 서버간의 통신 과정에서 패킷이 중간에 탈취될 경우 사용자의 입력 데이터가 그대로 노출됩니다. 이를 보완하기 위해서 HTTPS를 사용하여 패킷이 중간에 탈취되어도 사용자 및 서버가 송신한 데이터를 알아볼 수 없게 하기 위함입니다.

• 서버는 브라우저에게 CA( Certificate Authority )에서 발급받은 인증서를 응답하고 브라우저는 CA에게 해당 인증서가 정말로 해당 사이트에서 발급받은 인증서인지 확인하여 신뢰할 수 있는 사이트인지 검증합니다.

SSL/TLS 이란?

• SSL( Secure Socket Layer )는 Netscape Communications Corporation에서 웹 브라우저와 웹 서버간의 보안을 위해 만든 프로토콜로서 대칭키, 비대칭키를 기반으로 암호화된 통신을 합니다. TLS( Transport Layer Security )는 SSL의 취약점을 보완한 업그레이드된 버전으로서 현재는 SSL과 TLS을 동일하게 취급하고 있습니다.

대칭키와 비대칭키를 혼합해서 사용하는 이유

• 대칭키는 암호화와 복호화에 사용되는 키가 동일하여 해커가 해당 키를 알아내었을 때 쉽게 복호화가 가능하다는 단점이 있습니다. 이러한 단점을 보완한 것이 비대칭키로서 A, B 키가 있을 때 A로 암호화한 패킷은 B 키로만 복호화할 수 있습니다. 하지만, 그만큼 암호화 복호화 연산의 비용이 크다는 단점이 있기 때문에 SSL/TLS는 대칭키와 비대칭키를 혼합하여 사용합니다.

HTTPS 통신 과정

1. 1. 서버는 한 쌍의 공개키와 개인키를 생성한 후 서버 내 사이트의 각종 정보와 자신의 공개키를 CA에 전달하여 SSL/TLS 인증서 생성을 요청합니다.

2. 2. CA는 서버의 도메인을 비롯하여 각종 정보를 담은 인증서를 발급한 후 자신의 개인키로 SSL/TLS 인증서를 암호화하여 서버에 전달합니다.

3. 3. 웹 브라우저는 접속하려는 서버로부터 응답 받은 SSL/TLS인증서를 CA의 공개키를 이용하여 SSL/TLS 인증서를 복호화하여 신뢰할 수 있는 서버인지 확인합니다. 그리고 SSL/TLS인증서에 담겨있는 서버의 공개키를 확보합니다.

4. 4. 웹브라우저는 대칭키를 생성하고 SSL/TLS 인증서에 담겨있는 서버의 공개키로 웹 브라우저가 생성한 대칭키를 암호화하여 서버에 전송합니다.

5. 5. 서버는 웹 브라우저가 자신의 공개키로 암호화하여 전달한 패킷을 개인키로 복호화하여 웹 브라우저에서 생성한 대칭키를 확보합니다.

6. 6. 서버와 웹 브라우저는 안전하게 대칭키를 공유하게 되었으며 이를 통해 HTTP 메시지를 암호화, 복호화하여 통신합니다.

REST(REpresentational State Transfer)란?

• REST(REpresentational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다. 로이 필딩(Roy Fielding)은 HTTP를 목적에 맞게 그리고 보다 실용적이게 사용하기 위해 REST 아키텍쳐를 정의하였습니다.
  
  
  
  

CRUD Operation이란?

• CRUD는 대부분의 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create, Read, Update, Delete를 일컫는 말입니다.

CRUD Operation과 HTTP Method

• CRUD Operation과 HTTP Method를 맵핑하면 위와 같은 표로 구성됩니다.

REST 구성 요소

1. 자원(Resource) : HTTP URI

2. 자원에 대한 행위(Verb) : HTTP Method

3. 자원에 대한 행위의 내용(Representations) : HTTP Message Payload

REST 특징

1. Server-Client 구조

• REST API를 이용하여 서로간의 의존성을 줄인 독립적인 Server, Client 구조를 가집니다.

2. Stateless

• HTTP 프로토콜을 기반으로 하기 때문에 서버가 클라이언트의 상태를 보존하거나 기억하지 않습니다.

3. Cacheable

• HTTP 프로토콜을 그대로 사용하기 때문에 HTTP의 기능인 캐싱 기능을 사용할 수 있습니다. 

4. Uniform Interface

• identification of resources(자원에 대한 식별) :
  URI를 통해 자원을 식별할 수 있어야 합니다.

• manipulation of resources through representations(표현을 통한 자원에 대한 조작) :
  표현된 자원에 대해서 조작할 수 있어야 합니다.

• self-descriptive messages(자기 서술적 메시지) :
  자기 서술적 메시지로서 요청, 응답 메시지만을 가지고 해석할 수 있어야 합니다. 이러한 해석을 만족하려면 Host 헤더에 Host 이름 또는 IP를 기재해야 하고, Media Type을 정확하게 표기해야 합니다.
  
  HTML은 각 태그마다 목적이 명확하게 명세화가 되어 있어 self-descriptive message를 만족하지만, json 같은 경우에는 파싱에 대한 규칙만 정해져 있기 때문에 application/json 만으로는 self-descriptive message를 만족할 수는 없습니다.
  
  self-descriptitive message를 만족하려면 IANA에 Media Type을 등록하던가 link 헤더에 데이터에 대한 명세를 profile로 등록해서 self-descriptitive message을 만족할 수 있습니다.

• hypermedia as the engine of application state(HATEOAS) :
  Hypermedia를 통해서 애플리케이션의 상태 전이 또는 자신에 대한 정보를 확인할 수 있는 정보가 담겨야 합니다.
  
  HATEOAS를 만족할 경우 서버는 link를 언제든지 마음대로 바꿀 수 있습니다. 즉, 클라이언트는 고정된 link가 아닌 서버에서 받은 동적 link를 통해서 상태 전이를 할 수가 있습니다.
  
  HATEOAS를 만족하려면 link 헤더를 사용하던가, 또는 body에 link에 대한 정보를 넣고 이에 대한 명세를 link 헤더에 profile로 등록하여 만족시킬 수 있습니다.

5. Layered System

• API 서버는 순수 비지니스 로직을 수행 합니다.

• 클라이언트는 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지 인지 할 수 없으며, 이를 통해 중간 서버 (로드 밸런싱, 공유 캐시)를 제공함으로써 시스템 규모 성능 및 확장성 향상 됩니다.

6. Code on demand (optional)

• 서버가 클라이언트에게 코드를 응답해주면, 클라이언트는 응답 코드를 실행 할 수 있습니다. ex) JavaScript

REST의 장점

• HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능합니다.

• Client와 Server간의 의존성이 없기 때문에 독립적인 업데이트가 가능합니다.

• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.

REST의 단점

• HTTP Method 형태가 제한적입니다.

• 표준이 존재하지 않아 올바른 REST API 작성 및 관리의 어려움이 있습니다.

REST API란?

• REST API란 REST 아키텍쳐 스타일을 따르는 API를 말합니다.(아키텍쳐 스타일은 제약 조건들의 집합을 의미합니다.)

RESTful이란?

• RESTful이란 REST API의 설계 규칙을 올바르게 지킨 시스템을 말합니다. RESTful 시스템을 잘 지킨 서비스는 URI와 HTTP Method만을 가지고 어떤 요청을 하는지 파악하기 용이합니다.

REST API 설계 시 주의사항

• REST API를 올바르게 설계하기 위해서는 아래와같은 규칙을 지켜야합니다.

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용해야 합니다.

2. 슬래시( / )로 계층 관계를 표현합니다.

3. URI 마지막에는 슬래시(/)를 포함하지 않습니다.

4. 언더바(_) 대신 하이픈(-)을 사용합니다.

5. 파일 확장자는 URI에 포함하지 않습니다.

6. 자원에 대한 행위를 URI에 포함하지 않습니다.

7. REST API로 요청한 데이터는 HTML,CSS가 아닌 JSON 또는 XML 형식으로 반환합니다.

8. HTTP 응답 상태 코드 사용한다

• 1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다.

• 2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.

• 3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요합니다.

• 4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.

• 5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.

REST API 예외상황

• GET, DELETE Method는 body를 사용할 수 없기 때문에 개발하는데 있어서 예외적으로 POST와 같은 다른 Method를 사용해야 하는 경우가 있습니다.

• 클라이언트 요청에 대한 성공과 오류에 대한 메시지를 HTTP 상태 코드를 사용하여 소통을 합니다.

메일 서버

• 메일 서버는 사서함(Mail box)가 존재합니다. 그리고 이 사서함을 가지고있는 메일 서버간의 통신을 통해서 원격지에 있는 클라이언트끼리 메일을 주고 받을 수 있습니다.

메일 클라이언트

• 메일 클라이언트는 메일 서버의 사서함에 저장된 메일을 가져와 사용자에게 보여주거나 작성한 메일을 서버로 전달하는 역할을 수행합니다.

메일 서버와 메일 클라이언트 통신 방식

• 메일 클라이언트가 메일 서버로 또는 메일 서버가 다른 메일 서버로 메일을 송신할 때 SMTP를 사용하며, 메일 클라이언트가 메일 서버로 부터 메일을 다운로드 받을 때 IMAP 또는 POP3를 사용합니다.

SMTP( Simple Mail Transfer Protocol )

• SMTP는 메일을 전송할 때 사용하는 프로토콜입니다. SMTP가 사용되는 경우는 크게 두 가지입니다.

1. 클라이언트가 작성한 메일을 서버로 전송할 때

2. 메일 서버가 다른 메일 서버로 메일을 전송할 때

POP3( Post Office Protocol 3 )

• POP3는 메일을 수신할 때 사용하는 프로토콜의 한 종류로서 클라이언트가 메일 서버에 도착한 메일을 메일 서버로 부터 받아올 때 사용합니다. POP3에서 3은 version을 의미하며 현재 POP의 버전이 세 번째임을 의미합니다. POP3의 경우 메일 서버의 사서함( Mail box )로 부터 클라이언트 PC로 메일의 모든 정보를 직접 다운로드 하는 방식입니다. 또한 다운로드와 동시에 사서함에 있는 메일이 삭제되는 것이 기본적인 특징입니다.

POP3의 장점

• 오프라인 상태여도 메일 서버로부터 메일을 다운로드한 PC에서 다운로드된 메일을 지속적으로 확인할 수 있습니다.

POP3의 단점

• 메일 서버로부터 메일을 다운로드 후 메일 서버 사서함에 있는 메일을 삭제하기 때문에 별도의 설정 없이는 다른 PC에서 메일을 확인할 수 없습니다.

• 로컬PC에 문제가 생기거나 로컬PC에 있는 메일을 삭제하면 메일 서버에서도 이미 메일은 삭제된 상태이기 때문에 이후 삭제한 메일은 확인할 수 없습니다.

IMAP( Internet Message Access Protocol )

• IMAP은 POP3와 마찬가지로 메일을 수신할 때 사용하는 프로토콜의 한 종류입니다. IMAP의 경우 메일 서버와 클라이언트가 동기화되는 방식이며 POP3처럼 메일을 메일 서버로부터 받아온 후 메일 서버의 메일을 삭제하지 않습니다.

IMAP의 장점

• 동일한 메일 계정이라면은 여러 단말기에서 동일하게 지속적으로 메일을 확인할 수 있습니다.

• 수신자 클라이언트가 수신된 메일을 확인할 때 메일의 헤더 부분만 보여주고 수신자가 해당 메일을 클릭해야만 메일 내용과 첨부파일 등의 본문을 다운로드하기 때문에 POP3보다 빠른 방법으로 메일을 확인할 수 있습니다.

IMAP의 단점

• 메일을 확인할 때 마다 클라이언트와 메일 서버간의 통신을 해야하기 때문에 오프라인 상태에서는 메일을 확인할 수 없습니다.

• 개인 메일함의 용량이 정해져 있기 때문에 용량 관리가 필요합니다.

블로킹 소켓 ( Blocking Socket )

• 블로킹 소켓은 소켓 함수를 호출했을 때 현재 수행할 수 없다면 수행할 수 있을 때 까지 block 되는 소켓을 말합니다.

넌블로킹 소켓 ( Nonblocking Socket )

• 넌블로킹 소켓은 소켓 함수를 호출했을 때 현재 수행할 수 없다면 블락되지 않고 error를 return 하는 소켓을 말합니다.

블로킹 소켓과 넌블로킹 소켓 함수의 차이

accept()

블로킹 소켓

• 현재 백로그 큐 ( Backlog Queue ) 에 연결 정보가 없다면 연결 정보가 Enqeue 될 때 까지 블락됩니다.

넌블로킹 소켓

• 현재 백로그 큐 ( Backlog Queue ) 에 연결 정보가 없다면 INVALID_SOCKET 을 return 하며 WSAGetLastError(); 를 호출할 경우 WSAEWOULDBLOCK 이 return 됩니다.

connect()

블로킹 소켓

• SYN 패킷을 보낸 후 상대방으로부터 응답이 올 경우 return 됩니다.

넌블로킹 소켓

• SYN 패킷을 보낸 직후 바로 SOCKET_ERROR를 return 하며 WSAGetLastError(); 를 호출할 경우 WSAEWOULDBLOCK 을 return 합니다.

send()

블로킹 소켓

• 소켓 송신 버퍼의 남은 공간이 송신하려는 데이터 크기보다 부족할 경우 소켓 송신 버퍼의 공간이 확보될 때 까지 블락됩니다.

넌블로킹 소켓

• 소켓 송신 버퍼의 남은 공간이 송신하려는 데이터 크기보다 부족할 경우 남은 공간만큼 복사 후 소켓 송신 버퍼에 복사한 크기만큼 정수 형태로 return 합니다.

recv()

블로킹 소켓

• 소켓 수신 버퍼의 수신된 데이터가 1byte 라도 없으면 소켓 수신 버퍼에 수신 데이터가 복사될 때 까지 블락됩니다.

넌블로킹 소켓

• 소켓 수신 버퍼의 수신된 데이터가 1byte 라도 없으면 SOCKET_ERROR 를 return 하고 WSAGetLastError(); 를 호출했을 때 WSAEWOULDBLOCK 을 return 합니다.

네트워크 계층 구조란?

• 네트워크 계층 구조란 네트워크 통신에 필요한 로직을 역학별로 구분하여 계층화된 구조를 말합니다.

• 대표적인 네트워크 계층 모델로는 ISO(국제 표준화 기구) 에서 정의한 OSI 7계층과 TCP/IP 4계층이 있으며, 계층 구조의 차이는 있지만 서로 동일한 네트워크 프로토콜 표준을 따르고 있습니다.

네트워크 계층 구조가 필요한 이유

• 네트워크 통신에 필요한 로직을 역할별로 계층화하고 특정 계층이 다른 계층에 영향을 주지 않도록 구분하여 네트워크 통신에서 과정에서 문제가 발생되었을 때 보다 쉽게 원인을 찾거나 해결할 수 있습니다.

OSI 7계층

7. 응용 계층 ( Application Layer )

• 최종적으로 송.수신된 데이터를 이용해 응용 프로그램 사용자를 위한 로직을 수행합니다.

사용 가능 프로토콜

• HTTP, FTP, SMTP, DNS 등이 있습니다.

패킷 이름

• 응용 계층에서 생성된 데이터를 메시지라고 부릅니다.

6. 표현 계층 ( Presentation Layer )

• 송.수신 데이터에 대한 인코딩, 디코딩을 담당합니다.

5. 세션 계층 ( Session Layer )

• 세션 수립, 관리, 파기를 담당합니다.

4. 전송 계층 ( Transport Layer )

• 포트를 이용하여 송.수신 대상이 되는 소켓을 특정할 수 있습니다.

• TCP를 이용할 경우 안전한 송.수신이 가능합니다.

사용 가능 프로토콜

• TCP, UDP

패킷 이름

• TCP는 세그먼트, UDP는 데이터그램으로 부릅니다.

네트워크 장비

• L4 로드 밸런서

3. 네트워크 계층 ( Network Layer )

• 논리적 주소인 IP 주소와 서브넷 마스크를 이용해서 목적지 호스트의 네트워크 ID를 식별하고 이를 통해 서로 다른 네트워크에 있는 호스트간에 통신을 담당합니다.

사용 가능 프로토콜

• ARP, RARP, ICMP 등이 있습니다.

패킷 이름

• 네트워크 계층에서 생성된 패킷 이름을 IP 패킷으로 부릅니다.

네트워크 장비

• L3 라우터

2. 데이터 링크 계층 ( Data Link Layer )

• 물리적 주소인 MAC 주소를 이용한 노드 대 노드 전송을 담당하며, 트레일러로 추가된 FCS(Frame Check Sequence) 을 통해 이더넷 프레임의 오류를 감지합니다.

패킷 이름

• 데이터 링크 계층에서 생성된 패킷 이름을 이더넷 프레임 으로 부릅니다.

네트워크 장비

• L2 스위치

1. 물리 계층 ( Physical Layer )

• 전기 신호를 물리 신호로 또는 물리 신호를 전기 신호로 변환해주는 계층입니다.

TCP/IP 4계층

• TCP/IP 4계층은 아래 사진과 같이 계층 구조의 차이가 있지만, 동일한 네트워크 프로토콜 표준을 따르고 있어 호환됩니다.