5월 15, 2019 10:34:56 오전 org.apache.coyote.http11.AbstractHttp11Processor process
정보: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.

서버에 해당 값 오류가 발생하기 시작했습니다.

헤더 정보를 파싱하다 발생한 오류입니다. 파싱을 실패하는 이유는 여러가지 존재하지만, 현재 시스템이 cookie를 많이 사용하는 기반이기 때문에, cookie 설정을 확인했습니다.

tomcat 의 server.xml 을 보면,

<Connector  connectionTimeout="20000"
       port="8080"
       protocol="HTTP/1.1"
       redirectPort="8443"
       maxHttpHeaderSize="8192"
       maxThreads="150"
       minSpareThreads="25"
       enableLookups="false"
       acceptCount="100"
       disableUploadTimeout="true"
       maxPostSize="0"
       URIEncoding="UTF-8"/>

에서 확인할 수 있습니다. (local의 connector를 예제로 적었습니다. ) 여기서, maxHttpHeaderSize 를 수정하면 되는데, 예전에 해당 값을 늘렸었습니다.

그래서 원인을 못찾고 있다가, 실제 메시지 요청에서도 400 bad request 가 발생하는 현상을 확인하게 되었습니다.

175.213.173.54 - - [17/May/2019:07:59:47 +0900] "GET /rtb/xxx HTTP/1.1" 400 - "https://googleads.g.doubleclick.netxxx" "Mozilla/5.0 (Linux; Android 9; SM-G965N Build/PPR1.180610.011) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.128 Whale/1.0.0.0 Crosswalk/23.69.590.22 Mobile Safari/537.36 NAVER(inapp; search; 592; 10.3.2)" 0ms "IP_info: 175.213.173.54.58834 , fp: - ,Start_Time: 2018081901"

400 bad request 발생 조건 중에 하나가 cookie 의 예정된 길이를 초과했을 경우에 발생하는 것을 확인할 수 있었습니다. 그래서 다시 확인해보니,

http (80) 은 수정이 되어있었는데 https(443) 은 인증키를 바꾸는 과정에서 누군가, 해당 maxHttpHeaderSize 를 지운 것으로 확인되어, 해당값을 늘리면서 해결할 수 있었습니다.

         <Connector port="443" keystoreFile="keystore_path"                
                keystorePass="password" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="4000" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="false" connectionTimeout="8000" maxHttpHeaderSize="40960" />

maxHttpHeaderSize=”40960” 로 설정하여, 문제를 해결했습니다.

참조

• tomcat_maxHttpHeaderSize

2010년, 그러니까 9년전쯤 X-Forwarded-For 문제가 있었습니다.
해당 현상을 확인하기 위해,
삼성쪽 SE 분과 전화로 많은 요청을 하고 처리를 해왔었고,

결국 해답을 해외 문서에서 확인할 수 있었는데요.

요근래는 정말 내용 찾기가 쉽네요.
참고주소

현재 동일한 현상이 발생하고 있는데,

예전에 처리한 것처럼, X-Forwarded-For 의 정보가 없는 상태고, 추측으로는 L4 에서 네트워크를 한번 더 거치면서 해당 IP 가 그쪽 네트워크로 copy 되고 있는 현상으로 보였습니다.

L4 셋팅을 하다가, NAT 설정이 ON 되어있었던 것으로 밝혀져, 방화벽 정책 설정에 NAT 설정이 ON되어 있어서 해당 설정을 OFF 로 변경하며 해당 상황이 closing 되었습니다.

df -h 나, htop, ifconfig 와 같은 상태를 확인할 명령어 이외에는 어플리케이션쪽 명령어만 자주 사용합니다.
실제로 htop 같은 경우도 별도의 isntall 하지 않는한 쓸 이유가 별로 없지요.

HDD 는 느리고, SSD 가 빠르다는 전제조건때문에, 요근래 서버 구성시 was는 무조건 SSD를 선택하게 됩니다. 가격도 큰 차이가 없고, HDD 보다 성능이 압도적으로 높기 때문에

개발자의 인권비보다 하드웨어의 가격이 압도적으로 높아가는 시점에서,

lsblk -d -o name,rota

SSD 로 변경되어가는 추세입니다. 서버 상태가 느린 서버가 있어. SSD인지 HDD인지 확인하기 위한 명령얼을 찾다가 해당 명령어를 알게 되어, 히스토리로 남깁니다.

아래와 같이 명령어를 수행했을때 개별 디스크마다 출력이 되는데 1은 HDD, 0은 SSD이다.

lsblk -d -o name,rota
NAME ROTA
sda     0
sr0     1

sda 는 SSD 를 사용하고 있다고 보면됩니다.

lsblk -d -o name,rota
NAME ROTA
sda     1
sr0     1

sda 는 HDD 를 사용하고 있다고 보면됩니다.

또 다른 방법으로는,

cat /sys/block/sda/queue/rotational

를 쳤을 경우, 1 이면, hard disks!
0이면, SSD 입니다.