oxdjww.log

Intro 본 포스팅에서는 프록시 캐시와 캐시 무효화에 대해 다룬다. 프록시 캐시 원(origin) 서버에 직접 접근 원 서버에 클라이언트가 직접 접근하여 리소스를 받게 되면 병목현상이 일어날 수 있다. 프록시 캐시 도입 첫 번째 요청 첫 번째 요청에는 프록시 서버를 거쳐서 원 서버로 요청이 가게 된다. 첫 요청에는 프록시 서버에 리소스가 없으므로 당연한 결과이다. 그리고 원 서버로부터 응답이 오게 되면, 캐시 서버는 이를 캐시로 저장한다. 두 번째 요청 두 번째 요청 시에는 프록시 캐시 서버가 클라이언트들에게 응답을 함으로서 더 빠른 속도로 응답할 수 있다. 이렇게 프록시 캐시 서버에서 저장할 수 있는 캐시를 public 캐시라고 한다. 반면에 클라이언트가 보유하고 있는 캐시는 private 캐시이다...

Intro 본 포스팅에서는 HTTP의 전송 방식에 대해 다룬다. 전송 방식 HTTP 전송 시에는 다양한 전송 방식이 존재한다. 단순 전송 압축 전송 분할 전송 범위 전송 단순 전송 Content-Length로 길이를 명시하고, 단순히 전송한다. 압축 전송 Content-Encoding으로 압축 타입을 명시하고, 본문에는 압축된 데이터를 보낸다. 분할 전송 Transfer-Encoding필드에 chunked 값을 주고, 데이터를 분할하여 보낸다. 용량이 매우 큰 데이터를 보낼 때 사용한다. 총 크기를 예측할 수 없기에 Content-Length를 사용해선 안 된다. 범위 전송 범위를 지정해서 요청에 대한 응답을 받는 전송 방법이다. 데이터를 보내다가 모종의 이유로 중간에 끊겼을 경우, 처음부터 다시 받을 ..

Intro 본 포스팅에서는 표현(Representation)과 협상(Negotiation)에 대해 다룬다. 표현 즉, 표현 헤더는 다양한 http header로 이루어져 있는데 이는 header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) 위와 같은 형태를 띄고, 표현 헤더는 하단의 표현 데이터(==메시지 본문, 바디, 본문)를 해석할 수 있는 대표 정보라고 해석할 수 있다. 표현 헤더의 구조 Content-Type : 표현 데이터의 형식 Content-Encoding: 표현 데이터의 압축 방식 Content-Language: 표현 데이터의 자연 언어 Content-Length: 표현 데이터의 길이 표현 헤더는 HTTP 요청, 응답 둘다 사용 Co..

Intro 본 포스팅에서는 HTTP header의 개요에 대해 다룬다. HTTP Header란 header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) 위와 같은 형식으로 구성되어 있으며, field-name에는 대소문자 구분을 하지 않는다. HTTP Header의 용도 HTTP 전송에 필요한 모든 부가정보 (start-line에서 명시된 정보를 제외하고) 메시지 바디의 내용, 메시지 바디의 크기, 압축 타입, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 ... 표준 헤더는 엄청 많다. ref : https://en.wikipedia.org/wiki/List_of_HTTP_header_fields 필요시 임의의 헤더를 추가할 수 있다. H..

Intro 본 포스팅에서는 HTTP 메서드의 종류와 이를 활용하여 API를 설계하는 방법을 다룬다. HTTP API URI 설계 회원 정보 관리를 하는 API를 설계하는 상황을 가정한다. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 초기 설계는 다음과 같다. 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member 초기 설계 수정 초기 설계는 좋은 설계가 아니다. API 설계는 리소스를 식별하여 설계하는 것이 가장 중요하다. URI에 대한 고민 URI란 Uniform Resource Identifier이다. 즉, URI를 통해 리소스를 식별할 ..

Intro 본 포스팅에서는 HTTP의 정의 및 특징 등 HTTP의 기본에 대해 다룬다. Contents HTTP의 정의 Client - Server 구조 Stateless Protocol 비 연결성(connectionless) HTTP Message HTTP의 정의 HTTP는 HyperText Transfer Protocol의 약자이다. HTTP 메시지로 다양한 데이터를 전송할 수 있다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML(API) HTTP의 역사 HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) -> RF..

Intro 본 포스팅에서는 웹 브라우저 요청 흐름에 대해 간단히 다룬다. 웹 브라우저 접속 상황 가정 웹 브라우저의 IP : 100.100.100.1 웹 브라우저에서 접속할 구글 서버 IP : 200.200.200.2 URL : https://www.google.com/search?q=hello&hl=ko 요청 흐름 주어진 URL 기반으로 IP와 Port를 찾아내고자 한다. www.google.com.이라는 이름을 가진 IP를 DNS server에 조회한다. scheme(protocol)이 https: 이므로 port는 자동으로 443으로 할당된다. 아래와 같은 HTTP request packet을 생성하여 보낸다. 전송 과정 google server는 수신한 HTTP request packet을 기반으..

Intro 본 포스팅에서는 URI에 대해 다룬다. URI? URL? URN? 다양한 용어들이 있다. 이 용어들을 다음과 같이 정리가능하다. | "URI는 Locater, Name 또는 둘다 추가로 분류될 수 있다." ref : https://www.ietf.org/rfc/rfc3986.txt - 1.1.3. URI, URL, and URN 다이어그램으로 나타내면 다음과 같다. URI(Uniform Resource Identifier) : 리소스를 식별할 수 있는 개념 URL(Uniform Resource Locator) : 위치를 통해 리소스를 식별할 수 있는 것 URN(Uniform Resource Locator) : 이름을 통해 리소스를 식별할 수 있는 것 ref : https://www.ietf.o..

Intro 본 포스팅에서는 Port에 대해 다룬다. IP 기반 통신의 의문점 노드끼리 통신을 주고 받을 때, 한 IP(노드)에서 여러개의 프로세스를 운영한다. e.g. 일반적으로 한 사용자가 컴퓨터에서 문서작업을 진행하며, 카카오톡도 이용하고, 웹 서비스로 이메일을 이용할 수도 있다. 이 때 여러 프로세스(어플리케이션)을 구분할 수 있는 식별자가 필요하다. 이 식별자로 Port가 쓰인다. Port란 같은 IP 내에서 프로세스를 구분할 수 있는 식별자이다. 0 ~ 65535까지 할당 가능하다. 0 ~ 1023을 well-known port라고 불리우며, 사용자가 직접 사용하지 않는 것이 좋다. FTP : 20, 21 TELNET : 23 HTTP : 80 HTTPS(HTTP + tls/ssl) : 443 ..

Intro 본 포스팅에서는 전송계층 프로토콜인 TCP, UDP 에 대해 다룬다. 인터넷 프로토콜 스택의 4계층 인터넷 상에서 통신을 주고 받을 때, 기본적으로 이 네 계층을 통해서 통신을 주고 받는다고 볼 수 있다. 통신 Overview 한 clinet가 "Hello, world!"라는 메시지를 인터넷 망에서 보내려고 할 때, 이 data payload가 각 계층을 지나간다. 이 때, 각 계층을 통과하며 header가 encapsulate된다. application layer에서는 socket library를 통해 전달된다. 전송 계층에서는 TCP/UDP 등의 header를 붙인다. 인터넷 계층에서는 IP header를 붙인다. 최종적으로 네트워크 인터페이스 계층에서는 MAC 주소를 기반으로 ethern..