2021 10 14
2021-10-14¶
테코톡 Virtual Memory¶
- 프로세스 전체가 메모리 전체에 올라오지 않더라도 실행 가능하도록 - 물리메모리 제약에서 벗어나 - 프로그램이 작은 메모리만 차지해서 더 많은 프로그램 동시 수행 - swap 하는데 필요한 IO 횟수 줄어듦
- CPU는 연산시 메모리를 참조함 - Register, Main Memory를 통해 빠르게 접근 - CPU는 Main Memory까지만 접근 가능 - Disk 접근할라면 OS 도움받아 IO 작업 진행
- 프로그램 실행은 해당 실행파일을 메모리에 올리는 과정 - fork() 프로세스 생성, exec() 로더 호출 - 논리주소 - 프로세스는 0부터 시작되는 주소 - 주소 바인딩 논리 주소와 물리주소 - 실행시간 바인딩은 주소 매핑 테이블로 관리 - 기존 레지스터 + MMU
- Swap Area - 하드디스크의 메모리 공간 역할로서의 확장 - OS에 의한 IO 작업 - 일반적으로 파일시스템보다는 빠름
- 가상메모리 - 모두 물리메모리 나눠서 사용하는 것 - 적당한 크기의 프로세스... 쓰다보면 기존 프로세스 스왑으로 내쫓고 IO가 발생 - 크기 크면 애초에 메모리에 올리지도 못해 - 메모리에 적당히 필요한 부분만 나눠서 올려두면 안될까? - 프로세스 중 필요한 부분만 메모리에 올려서 실행
- Demand Paging - 프로세스 주소 공간 페이지로 나눠서 관리 - 필요한 페이지라면 메모리에 올리자 - Valid bit로 메모리에 있는지 없는지 확인 - 운영체제에는 프로그램에는 세상에 지 프로세스만 있는거처럼 행동할 수 있게 지원
테코톡 Deadlock¶
- 두 개 이상의 작업이 서로 끝나기를 기다리다가 서로 할일 못하는 상태
- 둘 이상의 프로세스, 스레드가 한정된 자원을 얻지 못해 처리할 일 못하는 상태
- DB 트랜잭션 데드락 - DB가 업데이트 할떄 락걸자나? - 동일 레코드 동시에 업데이트 하면 데드락 발생
- 데드락 예방: 데드락 발생 조건 4가지를 없애자! - 상호 배제 조건 - 동시에 자원 접근 가능하게 하자 (현실적으로 불가능) - 점유 대기 조건 - 저 프로세스 끝나면 내가 시작하자 (너무 오래걸려. 주기적으로 어떤 자원 필요로 하는지 검사해야함) - 비선점 조건 - 순환 대기 조건
- 데드락 회피: - 과정 1. 자원 요청시 안정 상태로 남아있는지 사전 검사 2. 안정 상태라면 자원 할당 3. 불안정 상태라면 타 프로세스가 자원 해지할 때 까지 대기 - 탐지 및 회복 - 교착 상태 허용 - 시스템 탐지해서 교착중이라면 회복 알고리즘 실행 - 시스템 비용/특성에 따라 언제 실행시킬지 정하자 - 고려사항 - 희생자 선택 - 후퇴 (롤백) - 기아 상태
- 데드락 무시: - 그냥 무시하고~ 특별히 일어나지 않겠지 - 교착 상태의 발생 확률이 낮은 상황에서 주로 사용 - 사용자한테 물어봐서 프로세스 죽임
테코톡 Flex Layout¶
- normal flow - block: 부모 요소 너비를 다 차지 - inline: 부모 너비에 대해 컨텐츠 만큼만 차지
- flex - 요소들을 1차원으로 정렬 - 용어 - main axis: x축 - cross axis: y축 - flex_container: 컨테이너 - flex_item: 자식요소
- flex container 속성 - flex-direction: 플렉스 방향 - row, column, row-reverse, - writing mode, direction 을 통해 flex-direction을 무시하고 배치 가능 - flex-wrap: 컨테이너의 영역을 overflow 했을떄 item을 어찌 배치? - justify-content: main axis 기준 item 정렬 - center, space-between - align-items: cross axis 기준 item 정렬 - straight(부모 높이 통으로 가짐), center: 중앙 정렬
- flex item 속성 - order: -1: 맨앞으로 놔주세요! 아이템 개별의 순서를 줄 수 있음 - 문서 구조 유지한채 반응형 헤더 시각적으로 변경되는거 지원가능 - flex-basis: flex 아이템의 기본 크기 - 컨텐츠 크기 만큼 차지 - px, %, rem 등 설정 가능 - flex-grow: flex-item이 늘어날 비율을 결정하는 속성 - flex-shrink: flex-item 요소의 크기가 flex-container 보다 클 때 사용. - 설정된 숫자값에 따라 flex-container 요소 내부에서 flex-item 요소의 크기 축소됨 - flex: flex-grow, flex-shrink, flex-basis 의 축약형
Proxy 서버와 XFF¶
- 문제 상황
- WAS내의 코드
public ResponseEntity<TokenResponse> signInOAuth(@PathVariable String socialType, @RequestParam String code, HttpServletRequest request) { log.info("Remote Addr : {}", request.getLocalAddr()); TokenResponse tokenResponse = authService.oAuthSignIn(socialType, code, request.getRemoteAddr()); return ResponseEntity.ok(tokenResponse); }- 여기서 이게 이렇게 뜨네...? - getLocalAddr(): 172.17.0.1 - getRemoteAddr(): 172.17.0.3 - 내가 원하는건 요청한 클라이언트의 IP 인데? - 참고 - getLocalAddr() - 요청 받은 인터페이스의 IP 주소 반환 - getRemoteAddr() - 요청을 보낸 클라이언트나 마지막 프록시의 IP 주소를 반환
- 뭐가 문제냐면 - reverse proxy로 nginx를 도커에 띄워서 사용중 - proxy_pass http://192.168.0.11:8080 이렇게 요청을 프록시 서버가 보낸단 말이지? - 그 사이에 http 요청을 새로 만들어서 WS가 WAS에게 보내는 거야. 그러다 보니까 문제가 원본 클라이언트의 정보가 유실됨 - 그러다 보니까 getLocalAddr() 하면 도커 인터페이스의 IP 172.17.0.1 나오고, - getRemoteAddr() 하면 172.17.0.3 이 나오는거구나
- 해결 방안
- 참고: https://cornswrold.tistory.com/442
- X-Forwarded-For를 사용하자!
-
X-Forwarded-For: client_ip, proxy1_ip, proxy2_ip- 프록시 서버 거칠때마다 ip를 붙여서 사용 - nginx에서 X-Forwarded-For 헤더를 설정server { location ^~/api { proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_pass http://127.0.0.1:8080; } }- 이후 스프링에서 "x-forwarded-for" 헤더를 까자 ```java public String getIp(HttpServletRequest request) { String ip = request.getHeader("x-forwarded-for"); return ip != null ? ip : request.getRemoteAddr(); } ```
- X-Forwarded-For는 뭐지? - 참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/X-Forwarded-For - HTTP 프록시/로드 밸런서에서 "웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별"하는 표준 헤더 - 클라이언트와 서버 중간에서 트래픽이 프록시/로드밸런서 거치면 서버 접근 로그에는 로드 밸런스의 IP만 남음 - 클라이언트의 원 IP 주소를 보기 위해 X-Forwarded-For 요청 헤더가 사용됨 - 위치 종속적인 컨텐츠를 위해 사용됨 - 이 헤더 사용하면 클라이언트 IP 정보 노출하는 거니까, 주의해서 사용하자