CL's DevLog

캐시 기본 동작 캐시가 없을때 요청1 GET/star.jpg 첫번째 요청, 두번째 요청 동일 단점 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 느린 사용자 경험 캐시 적용 요청1 GET/star.jpg 응답 결과를 캐시에 저장 브라우저 캐시 (60초 유효) 요청 2 GET/star.jpg 캐시 유효 시간 검증 60초 유효 시 캐시에서 조회 네트워크를 탈 필요가 없음 이점 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 요청 3 GET/star.jpg - 캐시 시간 초과 다시 요청 캐시 데이터..

HTTP 헤더 개요 header-field = field-name ":" OWS field-value OWS (OWS : 띄어쓰기 허용) field-name은 대소문자 구문 없음 헤더 용도 HTTP 전송에 필요한 모든 부가정보 e.g. 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보... 표준 헤더가 너무 많음 필요 시 임의의 헤더 추가 가능 helloworld: hihi 헤더 분류 (분류 - RFC2616(과거)) General 헤더: 메시지 전체에 적용되는 정보 Request 헤더: 요청 정보 Response 헤더: 응답 정보 Entity 헤더: 엔티티 바디 정보 HTTP BODY message body - RFC2616(과거) 메시지 본문은 엔..

HTTP 상태코드 소개 상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리중 (거의 사용하지 않음) 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 만약 모르는 상태 코드가 나타나면? 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면? 클라이언트는 상위 상태코드로 해석해서 처리 미래에 새로운 상태코드가 추가되어도 클라이언트를 변경하지 않아도됨 e.g. 299 ??? -> ..

클라이언트에서 서버로 데이터 전송 클라->서버 데이터 전달방식은 크게 2가지 쿼리 파라미터를 통한 데이터 전송(uri 끝에 추가) GET 주로 정렬 필터(검색어) 메세지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라->서버 데이터 전송 4가지 상황 정적 데이터 조회 이미지, 정적 텍스트 문서 조회는 GET 사용 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 주로 검색, 게시판 목록에서 정렬 필터(검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 조회는 GET 사용 쿼리 파라미터 사용해서 데이터를 전달 -> GET /search?q=hello&hl=ko 쿼리 ..

HTTP API를 만들어보자 요구사항 회원 정보 관리 API를 만들어라 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URI(Uniform Resurce Identifier) 설계 (x) 회원 목록 조회 / read-member-list 회원 조회 / read-member-by-id 회원 등록 / create-member 회원 수정 / update-member 회원 삭제 / delete-member 가장 중요한 것은 리소스 식별 API URI(Uniform Resorce Identifier) 고민 리소스의 의미는 뭘까? 회원을 수정하고 조회하는게 리소스가 아니다! 회원이라는 개념 자체가 바로 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모두 배..

[모든 것이 HTTP] HTTP (HyperText Transfer Protocol) HTTP 메세지에 모든 것을 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) -> 서버끼리 통신할때 사용하는 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 지금은 HTTP 시대! HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전 기반 프로토콜 TCP : HTTP/1.1, HTTP/2 UDP : HTTP/3 현재 HTTP/1.1 주로 사용 HTTP/2, HTTP/3(성능 개선)도 점점 증가 F12 (오른쪽버튼 프로토콜 확인 가능) HTTP 특징 클라이언트 서버 구조 무상태 프로토콜(스테이스리스), 비연결성 HTTP ..

[URI] URI(Uniform Resource Idenfifier) 소스를 식별하는 통합된 방법 "URI는 로케이터(locator), 이름(name) 또는 둘다 추가로 분류될 수 있다" 이름은 찾기가 어려우므로 거의 URL만 쓴다. URI 단어뜻 Uniform : 리소스 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL, URN URL - Locator : 리소스가 있는 위치를 지정 URN - Name : 리소스에 이름을 부여 위치는 변할 수 있지만 이름은 변하지 않는다. URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음 URL 전체 문법 schem://[userinfo@..

0. 소개 모든 것이 HTTP 기반 위에서 동작 개발자는 평생 HTTP 기반위에서 개발해야하므로 반드시 정리가 필요! 1. 인터넷 네트워크 [IP(인터넷 프로토콜)] 인터넷에서 컴퓨터 둘은 어떻게 통신할까? IP(인터넷 프로토콜) 지정한 IP 주소(IP Adress)에 데이터 전달 패킷(Packet)이라는 통신 단위로 데이터 전달 IP 패킷 정보 출발지 IP, 목적지 IP, 기타 ... IP 프로토콜의 한계 비연결성 대상이 서비스 불능, 패킷 전송 비신뢰성 패킷 소실 패킷 전달 순서 문제 발생 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면? -> 이런 문제를 해결해주는 것이 TCP, UDP [TCP, UDP] 인터넷 프로토콜 스택의 4계층 애플리케이션 계층 - HTTP..