dul2's DevLog

캐시 캐시(cache, 문화어: 캐쉬, 고속완충기, 고속완충기억기)는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간없이 더 빠른 속도로 데이터에 접근할 수 있다. 캐시는 시스템의 효율성을 위해 여러 분야에서 두루 쓰이고 있다. 웹 개발에서의 캐시는 주로 서버에서 반복적으로 동일한 요청을 받아서 결과를 돌려주어야 할 때(이미지, 썸네일 등)나 접근 시간에 비해 원래 데이터에 접근하는 시간이 오래걸리는 경우에 사용을 하게 된다. 혹은 Web Client Cache처럼 클라이언트의 웹 브라우..

header에 사용할 수 있는 또한 사용해야 하는 다양한 옵션들을 알아보자! 전송 방식 전송 방식에는 단순 전송, 압축 전송, 분할 전송, 범위 전송 이렇게 4가지가 존재한다. 단순전송 컨텐트의 길이를 정확히 알 때 전체를 단순하게 보내는 전송이다. 압축전송 서버에서 gzip과 같은 방식으로 압축하여 보내는 전송이다. 실제로 유의미한 압축률을 보이게 된다. header에 `Content-Encoding: gzip` 과 같이 압축 방식을 함께 전송해야 한다. 분할전송 `Transfer-Encoding: chunked` 옵션을 사용하여 분할하여 전송하게 된다. 분할 전송 때에는 길이를 가늠할 수 없기 때문에 Content-Length를 표기하지 않는다. 범위전송 `Range: bytes=1001-2000`처..

HTTP 헤더 HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보(메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...)를 포함한다. 표준헤더의 종류는 상당히 많으며 필요시 임의의 헤더를 추가 가능하다. HTTP 헤더 형식 Content-Type: application/json header-field = field-name":" OWS field-value OWS (OWS:띄어쓰기 허용) HTTP 헤더 분류 - RFC2616(과거) 과거에는 HTTP 헤더가 크게 다음과 같이 분리되어 있었다. General 헤더: 메시지 전체에 적용되는 정보 ex) Connection: close Request 헤더: 요청 정보 ex) User-Agent: Mozi..

HTTP 상태코드 HTTP 상태코드란 클라이언트가 서버로 보낸 요청의 처리가 잘 진행 되었는지를 응답에서 알려주는 기능을 말한다. 상태 코드는 100~500번대 까지 존재하며 각 100번 대마다 가지는 의미는 다음과 같다. 1xx (Informational): 요청이 수신되어 처리중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 그런데 만약 위의 상태코드 이외의 299와 같은 새로운 코드가 나타나면 어떻게 할까? 미래에서 새로운 상태 코드가 추가 되더..

HTTP 메서드 활용 클라이언트에서 서버로 데이터 전송 HTTP API 설계 예시 클라이언트에서 서버로 데이터 전송 클라이언트에서 서버로 데이터를 전송하는 방식은 크게 2가지가 있다. 쿼리 파라미터(?)를 이용한 데이터 전송과 메시지 바디를 통하여 전송하는 방식이 있다. 전자인 쿼리 파라미터 방식은 GET메서드를 통하여 URI에 쿼리 파라미터를 붙여 KEY-VALUE 형식으로 데이터를 보내며 주로 정렬 필터(검색어)를 사용할 때 사용한다. 후자인 메시지 바디를 통한 방법은 POST, PUT, PATCH가 해당되며 주로 회원 가입, 상품 주문, 게시글 등록, 수정과 같은 곳에 사용된다. 이렇게 2가지 방법을 통해서 다양한 상황들이 연출되는데 예시를 통해 알아보자. 정적 데이터 조회 - 이미지, 정적 텍스트..

HTTP 메서드 만들기 만약 회원에 대한 CRUD 요구사항에 따라 URI를 만들게 된다면 다음과 같이도 만들 수 있을 것이다. 회원 목록 조회 : /read-member-list 이렇게 만드는 것이 좋을까? RESTFUL api에 대해서 알고 있는 나는 좋지 않다고 생각할 것이다. 왜 일까? API URI 고민 해보기 URI를 정의함에 있어 가장 중요한 것은 리소스이다. 이전 글에서 URI를 설명함에 있어 리소스를 식별하는 통합된 방법이라고 정의했다. 우리는 리소스를 얻기 위해 접근하기 때문이다. 그렇다면 리소스의 의미는 뭘까? 단순히 회원을 등록하고 수정하고 조회하는 CRUD 과정이 리소스인 것이 아니라 회원이라는 개념 자체가 리소르를 의미한다. 더 나아가 리소스는 어떻게 식별하는 것이 좋을까? 이에 ..

모든 것이 HTTP HTTP : HyperText Transfer Protocol HTTP는 하이퍼텍스트(문서간의 링크)를 통해 이동하는 html을 전송하는 프로토콜로 시작을 했다. 하지만, 현재는 이미지, 영상, 음성 등 모든 형태의 데이터를 HTTP로 전송이 가능하다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터! 심지어는 서버간의 데이터를 주고 받을 때도 HTTP를 사용한다. HTTP 역사 HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) -> RFC2616 (1999) -..

URI란? URI란 Uniform Resource Identifier의 준말로 리소스를 식별하는 통합된 방법을 의미한다. 개발을 하다보면 URI이외에도 URL, URN 등 비슷한 의미로 쓰이는 다양한 단어들을 만나게 된다. 실제로 본인도 매번 검색을 했었다. 어떤 차이가 있는가? ietf에 이 스펙이 정리가 되어있다. URI는 로케이터(Locator), 이름(Name) 또는 둘 다추가로 분류될 수 있다. - Uniform Resource Identifier (URI) 문서 표준 스펙 즉, URI는 로케이터와 이름으로 분리되며 도식화 해보면 다음과 같을 것이다. URL은 Resource의 위치를 정의한 반면, URN은 이름으로 정의해놓고 통신할 때 이름으로서 찾는 것을 말한다. 표준스펙의 example을..

인터넷 통신 인터넷 통신은 local 망의 클라이언트 - 서버 간의 통신과는 다르다. 인터넷이라는 공용망을 통해서 클라이언트에서 서버로 통신을 보내야한다. 인터넷은 수 많은 node로 이루어져 있는데 그 중 내가 원하는 목적지로 이동하기 위해 또한, 안정적인 통신을 위해 특정 규칙을 통해 송수신을 하게 된다. 이 때 이해해야 하는 것이 IP(인터넷 프로토콜)이다. IP(인터넷 프로토콜) 먼저 인터넷 통신을 하기 위해서는 클라이언트 서버 모두가 IP 주소를 부여받아야 한다. 지정한 IP 주소(IP Address)에 데이터 전달 패킷(Packet)이라는 통신 단위로 데이터 전달 IP 패킷 정보가 가지고 있는 데이터 출발지 IP 목적지 IP 패킷이 인터넷 망의 많은 노드를 지나가면서 정해진 통신 규약을 따라 ..