WEB

📌 캐시 기본 동작 ✅ 캐시가 없다면? 데이터가 변경되지 않아도 매번 새로 데이터를 다운로드 받아야 한다 인터넷 네트워크는 매우 느리고 비쌈 > 브라우저 로딩 속도가 느림 > 느린 사용자 경험 ✅ 캐시 적용 후 1️⃣ 첫번째 요청 서버는 응답 메세지 헤더의 cache-control에서 캐시의 유효한 시간을 지정해서 응답 결과를 보낸다. 이 때 응답 결과는 브라우저 캐시에 저장된다. 2️⃣ 두번째 요청 클라이언트에서 이전에 사용했던 리소스에 대한 요청 메세지가 발생하면 먼저 브라우저 캐시에서 캐시 유효 시간을 검증한다. 브라우저 캐시에 유효한 데이터가 있으면 서버에 요청메세지를 보낼 필요 없이 바로 브라우저 캐시에서 리소스를 조회한다. 캐시 시간이 초과되면 서버에 재요청하고 캐시를 갱신한다. (네트워크 다..

📌 HTTP 헤더 ✅ 용도 HTTP 전송에 필요한 모든 부가정보를 담음 e.g 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등 표준 헤더 너무 많음 필요시 임의의 헤더 추가 가능 ✅ 분류 - RFC2616(과거) 폐기 General 헤더 : 요청 메세지, 응답 메세지와 상관없이 메세지 전체에 적용되는 정보 e.g. Connection: close Request 헤더 : 요청 정보 e.g. User-Agent: Mozilla/5.0 (Macintosh; ..) 웹브라우저 정보 Response 헤더 : 응답 정보 e.g. Server: Apache Entity 헤더 : 엔티티 바디 정보 e.g. Content-Type: text/html, Conte..

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

📌 클라이언트에서 서버로 데이터 전송 ✅ 데이터 전달 방식 🔻 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터에 사용(e.g. 검색어, 게시판 정렬 조건) 🔻 메세지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 ✅ 4가지 상황 🔻 정적 데이터 조회 이미지, 정적 텍스트 문서 조회는 GET 사용 단순히 리소스 경로만 지정해주면 서버가 리소스를 반환해줌 쿼리 파라미터를 사용하지 않음 추가적인 데이터를 필요로 하지 않음 🔻 동적 데이터 조회 검색어와 같은 추가 데이터를 전달해주기 위해 쿼리 파라미터를 사용함 주로 검색, 게시판 목록에서 정렬 필터(검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 조회는 GE..

📌 API URI 설계 ✅ API URI 설계 예시 요구사항 : 회원 정보 관리 API를 만들어라. 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member → 좋은 URI 설계일까? ✅ 리소스와 행위를 분리 먼저 리소스를 식별하는 것이 가장 중요하다. 리소스는 명사, 행위는 동사 회원이라는 개념 자체가 리소스이며 등록하고, 수정하고, 조회하는 것은 모두 배제한다. ✅ 리소스 식별, URI 계층 구조 활용 예시 회원 목록 조회 /members 회원 조회 /members/{id} 회원 등록 /members/{id} 회원 수정 /members/{id} 회원 삭제..

📌 HTTP HTTP : HyperText Transfer Protocol 문서 간 링크로 연결되어 있는 문서를 전송하기 위해 만들어진 프로토콜이지만 현재 거의 모든 자료를 전송할 수 있다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 서버 간 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. ✅ HTTP 버전 HTTP/1.1 : 현재 사용되는 대부분의 기능, 가장 많이 사용함, 가장 중요한 버전 HTTP/2와 HTTP/3은 1.1 버전에 성능을 개선한 버전이다. 1.1과 2는 TCP 프로토콜을 기반으로 사용하며 3 way handshake를 하기 때문에 전송해야 할 데이터가 많고 속도가 UDP 보다는 느리다. 반면 3은 UDP 프로토콜을 기반으로 사용하며 애플리케..

📌URI(Uniform Resource Identifier) URI : 리소스를 구별하는 통합된 방법을 나타내며 URL과 URN을 포함한다. URL : 리소스의 위치를 지정한다. URN : 리소스에 이름을 부여한다. 리소스의 위치는 변할 수 있지만 이름은 변하지 않는다. 현재 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았기 때문에 URN은 거의 사용하지 않고 URL을 많이 사용한다. 📌 URL 전체 문법 scheme://[userinfo@]host[:port][/path][?query][#fragment] https://www.google.com:443/search?q=hello&oq=hello ✅ scheme 주로 프로토콜 사용 프로토콜 : 어떤 방식으로 자원에 접근할 것인가에..

📌 인터넷 통신 클라이언트는 서버에게 요청(request)을 보내고, 서버는 클라이언트에 요청에 대한 응답(response)을 한다. 메세지를 전송할 때 복잡한 인터넷 망을 거치게 되는데, 메세지가 잘 전송되기 위해서는 일련의 규칙이 필요하다. 📌 IP(Internet Protocol) 복잡한 인터넷을 거쳐 메세지를 잘 전송하기 위해서 각 클라이언트와 서버는 각각 IP 주소를 부여받는다. 이때 IP는 지정한 IP 주소에 데이터를 전달하고, 패킷이라는 통신 단위로 데이터를 전달하는 역할을 한다. 전송하려는 데이터에 출발지 IP, 목적지 IP 등의 정보를 더해 IP 패킷으로 만든다. 📌 IP의 한계 하지만 IP에는 한계점들이 있다. 비연결성 : 패킷이 받을 대상이 없거나, 서비스 불능 상태여도 전송이 이루어..